How to build software: Do it. Document it. Then Automate it.
I ran a startup studio which consulted by building tech for 50+ startups over 6 years. These 3 steps are the most common advice I gave to anyone* wanting to build software.
Once you think you have the solution to a potential customer’s problem, the wrong move is to run off to raise some money, hire a team build lots of software and try to launch it 6–18 months later… The right move is to solve that problem today. Ideally for money. Then you solve it again. And again.
The reason this is better is because you have solved a customers problem. Secondly, because in doing so you’ll invariably learn a lot of new things that you didn’t know you didn’t know before. And getting real money is the best indicator that a problem is worth solving.
*The advice is most applicable to service based applications, but not exclusively.
Here’s how it works:
Step 1: Do it.
Whatever it takes to solve the customers problem, with the funds, time and capacity that you have available to you right now. Then do it again, maybe for a different customer. The things you’ll learn will astound you.
Step 2: Document it.
While you are doing the thing, over and over, start to write down the process. Map the flows and decisions. Template out all the messaging and copy. Do this well enough and you should be able to hire an intern to also do it for come more customers. Interns are cheap.
Step 3: Automate it.
Interns are also not very smart, so you need to be quite explicit. You can now start using some low code tools and services to string it together for you. Documenting explicitly how to run a process repeatedly to solve customers problems also happens to be exactly what developers need in order to actually write some code for you. Ideally, you’ve now run this enough times to not need make too many big complicated, and costly, changes along the way.
The benefits
The reason this works is because you don’t know what you don’t know. Every idea is filled with assumptions and uncertainty. Only a solution that has repeatedly been delivered helps you know those things. “Get out of the building” as they say.
For example, if you’re manually doing the matching in excel and sending emails then you can make changes on the fly. Every customer can be charged differently when you email your pricing. Experiments can be rapid and improvements constant. Once something is coded it’s slow to change (unless you’re the developer) as you need to explain it, and scope it, and add it to the backend, add it to the frontend, and test it and fix it…
Software developers are expensive. It helps to know exactly what you need them to build.
Oh, and you could solve the customers problem today well enough that they’d actually pay you for it. Having real revenue from real customers is a great way to persuade developers that they should work for you — or to find investors that will give you money to pay them...
So next time you have a great idea for an app/service/website, stop. Rather be Problem, not Solution focussed and go through the hard work of serving and learning — not the easy work of designing and speculating. You’ll save yourself a ton of time and money in the process.
