Productivity May 28, 2020

5 mistakes I made with my latest indie-project that you should avoid repeating

Sourav Ray @souravray

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.

1# Attempted to build something too complex

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.

2# Counted on unproven collaborators

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.

3# Building solutions for demography that you vaguely understand

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.

4# Not chalking out an incremental release plan

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.

5# Not getting out of the developer's mindset fast

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 nada.

  1. 2

    This is a great list thanks for sharing @souravray. Love #3 and its one I learned the hard way multiple times also. Doing customer interviews and lots of talking to end users is super necessary.

  2. 2

    I fall into the #3 problem a lot ... in college started working on an oral health management device for clinicians based on research data and realized that I didn't really know any people to test with. 200K in VC funding later we are still trying to do product-market fit because I haven't seen many of the problems my customers encounter.

  3. 2

    Oh man, I've been indie hacking off and on for 6 years now, and you've nailed every mistake I've made, pretty much in order!

    #1 is spot on! Us developers don't think much about adding another table to a database, but every single association is going to multiply the complexity of the link (you had an articles table with a create/read/update/delete, then you added comments and it doubled the complexity - another set of create/read/update/delete operations). And once they start interacting subtly beyond the main association, you're also adding edge cases. And on top of all that, we're really bad at estimating time!

    #3 is my biggest problem lately. I love helping people, expanding my horizons, and working on projects in areas I'm unfamiliar with. But I'm already an introvert, and outreach is really difficult!

    I'd really like to clarify in my head what sort of process there is to make sure my future ideas don't repeat this issue while also being fun, and don't explode in complexity :-D

  4. 2

    Good list. Three of these (#1, #4, #5) are directly a result of being a developer, which makes us too happy to just sit down and start coding. And all five are some form of being overly optimistic.

  5. 2

    I love the last sentence, thanks for the 6 Tips ;)

  6. 1

    Apparently it is very common for developers to attempt to solve problems that we don't experience ourselves. Nir Eyal is his book Hooked, described a Manipulation matrix.

    manipulation matrix

    If a maker doesn't use the solution, but hope the solution improves the user's life, then he/she is categorized as a Peddler. He further predicted this category is certain to fail, since "Peddlers tend to lack the empathy and insights needed to create something users truly want". It's a fair argument, but I will not agree with it fully.

    You need to be in constant touch with your (potential) uses even before you write the first line of code. Get your product constantly reviewed by them, and if possible get into their shoe. A few years back when I use to work with a food-tech startup, my colleague took a part time job as waitress in a restaurant close our office, and it helped us greatly to improve the product UX.

    If you are building solution for others, then you should be ready to go some extra mile to build it.