As someone who perpetually overscopes side projects and ends up biting off more than I can reasonably chew given my free time, I really love this idea. What happens with me is I start a new project, then add a new feature here and there (because coding is fun) and end up never reaching anything close to "done" then getting into analysis paralysis of what to do next because there is so much. Ultimately it gets abandoned and forgotten and put on the graveyard of all the other side projects - not that this is horrible, I do them for fun and not profit, but it would be nice to launch a few.
If OP is actually the author, a question - what was your approach in keeping the projects tightly scoped and not introducing feature creep? Deadlines or time-boxing? Pre-emptive deciding on what you will and won't do? Lowering your standards for "good enough"? Just plain old discipline? Something else?
Building for fun vs building for profit are very different and it's important to set your intention for a project, even though the line often gets blurred.
When you are building for fun, it is for yourself. When you are building for profit, it is for other people. When you are building for fun, you get to decide what to work on and when to stop - usually when it is no longer fun. When you are building for profit, other people decide what you work on and when you are done - usually when no new features are requested, you have no competition, and you have absolutely saturated your market. This rarely ever happens so you always have something propelling you.
The biggest failure most engineers encounter is they build things nobody asked for. They build products without customers lined up, for markets that do not currently exist, with only feedback from themselves. This is because they built the product for fun thinking they were building it for profit.
The line between the two is very easy to blur - especially when reading OP's blog where he genuinely sounds like he had fun building his projects, but I guarantee there was also a lot of very unfun background work done in the name of profit.
> Ultimately it gets abandoned and forgotten and put on the graveyard of all the other side projects
Could be worse. I used to have this problem all the time, and at some point managed to fix it. Now I've spent 3 years on a side project (which I originally thought should take a couple of months, and considering its lack of complexity really only should have taken at most a year), and even though I'm fully aware its an "unworkable" idea, I can't stop until its done.
I've read tiny projects in the past though and really like it, I really want to try a similar thing at some point...just as soon as this current project is done ;)
This idea comes up in painting. The rule of thumb is that it's done when there's nothing left to add; when adding the next thing does not provide much more value value than it costs in terms complexity.
With coding, it seems like it's much more difficult question to answer.
With coding, I often find Antoine de Saint-Exupéry helping me to limit myself: "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."
Or maybe more to do with users buying more of a particular brand of Bluetooth headphones and not having an arbitrary and universal input (you can do a lot of crazy stuff with an audio jack see square).
I suppose that might be one reading, though IMO the battery, jack, and card slot have just been replaced by more bells and whistles like more/fancier cameras, biometric sensors, NFC, and other gobbledygook that was more important to someone than being able to plug into the cassette adapter in my car. Not exactly what I think of when I hear "nothing left to take away."
If OP is actually the author, a question - what was your approach in keeping the projects tightly scoped and not introducing feature creep? Deadlines or time-boxing? Pre-emptive deciding on what you will and won't do? Lowering your standards for "good enough"? Just plain old discipline? Something else?