They (not Einstein) say that the definition of insanity is doing the same thing over and over again and expecting different results.

So, after failing to take my last bootstrapped SaaS business past the alpha stage in 2019, there are some things about my process that I have to change.

I spent some time reflecting on my last try and a few things stood out to me as fatal mistakes that doomed my business to be just another domain in my NameCheap account.

I'm going to break each one down in the hope that you will read this, and avoid the mistakes I made.

1. I Chose Technology I Wasn't Familiar With

As an engineer, I'm always looking to learn new technologies and further my knowledge in my field. It's vital to stay relevant and to stay valuable.

At the time, I was interested in Firebase and so decided that I would write my entire backend in the stack they provide. Even though it has decent documentation and isn't too complicated, it added extra friction.

This friction manifested itself in the form of burnout and without a doubt, contributed to the downfall of my first SaaS business.

Learning new technologies is great, however, bootstrapping a business isn't the time to do this.

As a solo coding founder, you will have a tonne of work on your hands, and not just coding either. Product design, UI/UX design, creating business systems, and more will all have to become a part of your day to day tasks.

Learning new technology doesn't have to be, and in most cases shouldn't be added to that list. Don't make things harder for yourself than they already are.

And if you are worried about your skills stagnating, don't. Where in a team you have other people to handle some of the issues that come up, as a solo coding founder you are going to have to learn how to handle ALL of them yourself.

Choose technologies that you are comfortable with, are productive in, and enjoy using. You'll thank yourself down the line.

2. I Didn't Have a Well-Scoped MVP

Yak-shaving, scope creep, and over-engineering, oh my!
Any professional developer will be painfully aware of the dangers of this deadly trio. That doesn't however, mean that we don't still fall into their traps.

Engineers love to engineer. We like to find clever solutions to hard problems, we like to optimise, and we like to experiment. This all leads us down a series of never-ending rabbit-holes, wasting time under the guise of "improving the product".

In a larger company, you may have the resources to get away with this. As I found out though, solo coding founders don't.

When I was coding up the MVP for my failed SaaS business, I had a loose idea, an approximate roadmap of what I wanted to build.

I didn't however, strictly define what should go in my MVP and what could come later. I didn't define the scope of the features that I did plan out either.

Because of this, I would often hear myself saying "There has to be a better way to…", "What if I…", or "I bet I could…". I would then open up a can of worms that was happy to stay shut, add in another "cool feature", or create a solution that is way too over-engineered (but it's future proof, right?).

This lead to a bloated MVP, with features in that I didn't know if people wanted or not, that got released way past its deadline.

When you are a solo coding founder, leave cans of worms tightly shut if they don't have to be opened. If you find yourself writing code and building features because "in the future, you might need to…" then stop.

If you don't need something right now, don't make it. You don't have time to build everything you need for the future of your product. Your product won't even have a future if you don't release it due to never-ending scope-creep.

Just in time development is vital when trying to bring your bootstrapped business to life as a solo coding founder.

Design your MVP, scope it, and stick to it.

---

Read the other key takeaways on the original post