September 2012 we had no product. Even not an idea. Today our SaaS product for architects is making almost $3K automated monthly revenue. And growing. How did I do this? You can read it in the “from service to products” blogpost series.
In September 2012, I decided that in a few years form now I wanted to be out of the hamster-wheel of a typical service business. Doing custom software projects is fun, but it is not scalable and is a lot of work for a medium return. The only way to earn more in a service business is by putting more hours into your business. I wanted to get off this hamster-wheel. I didn’t want to trade my time for money anymore. I decided to transform my service business into a product business. If others can do it, I can do it! And so you can if you just want it badly enough.
I can not describe how happy I was when we identified a burning pain in a niche market (architects wanted to get rid of the administration for site reports) after a lot of cold calling. It was even more exciting when were able to collect 1000 email addresses of people interested in a product that was not yet built! Even if we didn’t earn one single dollar and invested quite some time into the challenge, it felt great. And that’s because I knew we were on to something. Proof and evidence was there. I mean… 1000 email adresses collected via our coming soon page…how awesome is that? ALLRIGHTY!
How nice can life of a developer/bootstrapper be when you know that there are people out there waiting for your piece of software? It is so much more fun building something you know will be actually used.
There are way to much people on this earth who risk their reputation, spend all their evenings and weekends or loose their health building something whitout knowing if it will ever be used by someone or if people would pay them for their software. I mean…they didn’t even call potential customers to understand the problem before building the solution. Or they don’t know yet if people would actually pay for their software, aka “I’ll get 10 million users and then I’ll figure out how to make money…“. Ask Foursquare how that feels.
This is sad. And easily avoidable!
You know you can build software, you know you can figure out how to build it, or you know you can hire people to build it for you. So don’t do that first. Building software is the easy part (unless you are building software to reproduce a human brain or to launch rockets to the moon, but then you shouldn’t bootstrap). Start with the uncertain part, and eliminate risks one by one. Before opening up your favorite development environment, photoshop, your FTP server or the terminal, make sure you can answer those 2 questions very clearly and honestly for yourself:
- Do I solve a clearly defined problem for a niche market? Is that market willing to pay for my solution? Do you really solve a pain? Although we were sure that we hit a pain point after our many calls, I really didn’t want to take the risk building something that could fail. So I picked up the phone again and called another 40 random architects. I wanted to hear them saying: “yes, I would pay for this software“. It took me 2 hours extra calling, but potentially could have saved me months of development, frustration and hair loss.
- Can I reach my target market in a cost effective way? Even the best pain solving piece of software is worthless if you can not reach your target market. Make sure you are able to identify your niche market, make sure there are sites for your audience on which you can buy ads, there are LinkedIn groups where your targets are hanging around, there are forums for your market, you have interesting blog content for your audience, there are mailing lists, and so on. Those are all good signs that you are able to market them. “Spanish expats in the USA that play ping pong” is for example a very difficult niche to reach. Good luck finding a LinkedIn group with such members.
We decided to start building ArchiSnapper once we felt confident it would not fail. Maybe it would not become the next Basecamp, but we knew it would not be a complete disaster. We had already a small queue of interested people asking us when our product would be ready. Some people called us every two weeks to ask if there was any progress. We were quite sure that we would get a few K’s of monthly recurring revenue out of this.
When we invited our very first batch of 20 beta users (the most enthusiastic people, asking us weekly when it would be ready), we were a bit embarrassed. There were still bugs, unpolished layouts, and typos everywhere. We invited them on our testing environment to play and test the app. Like in a sandbox, not ment to be used for real. But most of them just started to use our app right away to send out construction site reports to their clients. From our buggy test server! Without any evidence or proof that the app would work. They didn’t even try it out first, they just start using it for real, from day one. And kept on using it. Also after the free beta trial was over. We actually had already 1K MRR (virtually) before being live!
This is great! Why? Because if people are using your app even if it’s buggy and ugly, it means you do solve a huge pain. The bugs and the non sexy interface is completely irrelevant for your users if they save hours of painless time and administration per week with your software! You don’t have to sell your software with tricks like the newest UI trends. It sells itself. And just imagine how much more users you will be able to get once the bugs are removed and the UI is really looking sexy.
This is why you should not focus on your logo, name, perfect code, ajax, autocompletion, and optimizing your code for performance just in case you hit 1M users. Focus on solving a pain and make sure you build up a waiting queue of clients before and during your developments. That makes it more fun to build and launch your software. Really.
Oh wait…before leaving. Writing this blogpost took quite some time, but tweeting, sharing and liking it will just take you a second. It would be great if you could hit the buttons below :-)