If you have read this blog previously you’d have noticed that I recently (as in, October last year) decided to start working on a business idea that I, and a number of others, thought was great. Unfortunately, that business idea is no more due to a number of reasons I’m going to outline below.

I actually held off writing this article due to embarrassment that I didn’t even manage to ship one version, but I feel that the lessons I have learned could truly help someone if they are facing similar issues.


The idea was simple: develop an application that allowed non-developers/testers to write automated tests. In my head, the MVP should have included the following:

  • Ability to create, edit and organise tests and their test cases.
  • Ability to create and modify reports through a report engine
  • User management
  • Test runners

Reasons for failure

Open sourcing the code

I’d like to prefix this by saying that I love open source. I love working on it, I love using it and I love writing about it, but it does have negatives when you’re trying to run a business.

My plan, ever since the inception of the “‘great’ business idea”, was to operate a paid & hosted/open-source and free, dual licensed application. Those wishing to use a reliable, scalable, no-infrastructre-neccessary hosted version of the software with enterprise-grade support could pay for the privilege. Those who wished to use the open source version and rely on community support were free to do so.

Unfortunately, with open sourcing comes people and companies crawling through every inch of your source code. With that comes rude comments, anxiety over how your public code represents you and fear around the impact your actions may have on your product. Some actions that open-source start-up founders make results in the community organising a witch-hunt to burn them at the stake for them changing their product, in a way they seem fit.

I think the combination of the anxiety about my code’s portrayal of me (which, I must say, usually is fine) and seeing other people who have made open-source businesses get sworn at, ridiculed and abused for the decisions they made on their free product really worried me and set the chain reaction of this product failing in motion.

Taking on more work than what I had time for

I run a contracting business full time, rent a house, have two dogs, a partner and a wonderful group of friends. Assuming I worked on the business for two hours a day in the evening for 6 days of the week, I’d have spent a total of 12 hours a week, or 48 hours a month on the business. To put it into perspective, that’s 8 hours off of what I normally work each week in my consultancy roles.

Now, you may say 48 hours a month is enough to get a large amount of work done. I’d tend to agree with you, if it was only development work that needed doing. However, when you run a business (or a start-up) as a sole founder, you are a marketer, a designer, a copywriter, a secretary and a developer. You cannot simply sit down and say “I’m going to develop this product to completion and sell it for thousands of dollars”. If nobody knows your product exists, you can’t sell it, so you end up spending around 30% of your time on developing, and the rest on other tasks crucial to your product succeeding.

This is therefore the number one reason why I think the business failed: I simply did not have enough time to complete the sheer amount of work required to get a shippable MVP ready. I could have dedicated more time to it, but this would have been at the expense of my family, my friends and my consultancy business, something which I was not prepared to do.

Not picking something that could have been done in a specific time-frame

This sort of links back to the previous point, but the project I picked did not have an acceptable time-frame for something to be developed, made into an MVP and shipped to customers. I was working on a multi-quarter plan for something that I didn’t even know would sell.

I know people often say you should “ship often” and “fail fast”, but you never really think to do that so religiously on your own product until you waste many months of your life on it. In reality though, “shipping fast” is the best advice you could ever receive as someone looking to sell their own product.

Pick something, give it a realistic time-box and try to sell/ship it within that time-frame. If you can’t, or if you lose the motivation to do so, there’s a good chance you’d never have been able to sell the finished version anyway.

Avoiding this in the future

I’m a big proponent of learning from your own mistakes and feel that I would never have come to the conclusions above had I not have gone ahead and tried doing it. However, in the future, I plan on doing the following whenever I want to make a product I can sell:

  1. Keep it closed-source, at least until I’m happy there is demand for it and am happy with the code-base.
  2. Pick a realistically-sized project.
  3. Give myself a time-frame to build, market and ship something sellable in.