In April I started building TinyDojo as a 2 weeks hack to help independent fitness instructors to run their business online. It quickly spun into a fulltime project, which is still an inch behind the beta release after 6 weeks of developments and redevelopments. I made some mistakes that you shouldn't, so I thought to jot them down here.
If your project has more than 3 screens (including the landing page) or more than 10 independent visual components, your a doing just more than a side project. Sometimes an idea looks deceptively simple to implement but during development, it leads to more complex use cases. Use a pen-paper wireframing to validate your idea. If you still want to pursue it, set a more realistic timeframe for yourself.
If you are dependent on collaborations for some reason (project complexity or skill gap), be sure that your associates also have the same level of passion for the project, and willing to contribute much as you. You cannot be both the Quarterback and the Cheerleader at the same time. Driving an uninspired team will only slow you down. If you ever get into a situation like that, cut them loose as quickly as possible.
I am a repeat offender here. I jumped into ideas without considering whether I am best placed to understand the end-users reality. For an indie project, it is too much burden. You need constant effort to reach out to potential users and get their feedback, else you end up building something that nobody wants.
It is tempting to incorporate all your initial ideas into the first-cut. Especially for the side-projects, since you considered them trivial. If you have avoided making the first mistake, then you are better placed to understand the true complexity. Break down your initial idea into 2-3 incremental releases. Have a plan B for things that you are not sure of.
This is the hardest part of being an indie developer. Some days back Hiten Shah twitted that there is always a choice of developing fewer features and releasing faster. Though we all will agree with him but putting it in practice is harder than it sounds. The de-facto developer instinct doesn't drive you to the same direction. You should set a rational plan and stick to it. It might be painful to ship half-becked features, but it is better than