Most of my side projects are the result of quick sprints. Periods of deep, Focused work in a relatively short amount of time.
That does not mean that I work on a given project only for a few weeks (although that’s the case for some of them). It means that the core functionality is ready relatively quickly. The rest takes way more time.
When you’re developing the core functionalities of your idea you are deeply invested it. You are eager to see your ideas confirmed and because of that the development is quicker and more straightforward. It’s the bells and whistles around it that take up the majority of the time.
But do you really need them? The difference between releasing a work in progress beta and a fully functioning 1.0 might be months or years.
There are two opposing schools of thought on this: The indie side of ship stuff quickly and the perfectionist side of ship stuff when ready. I usually tend to be moderate and pick somewhere in between.
The app should not be too early in the development cycle to be obvious to users that it is not ready. It should also not take a very long time to ship because you’re busy working on the bells and whistles.
The best way to do it is to limit the feature scope drastically.
Sure, while working you will think about new features and you might even add a few. Although you should add them to the backlog and consider if they really should be in the first release or not. If you start with very few and focused features you can go a long way to short your initial development time.