One of the things I have encountered as a tech guy for ambitious founders is that many times they want to hit the ground running with system design, but something you learn quickly when it comes to bringing ideas to the real world through a system is that it is impossible to design an effective system from the desktop. I think it’s a lot like when you’re learning a sport.
The first time you try to do burpees, you’re probably going to do them in a very inefficient way. For one thing, your muscles may not be optimized in composition for that type of workload. On the other hand, you don’t yet have the interoception to understand how your body works in a new movement pattern, and maybe your heart isn’t strong enough for that type of cardio. So first you have to do it that way, inefficiently, because you have no other way to do it, and only as you do burpees iteration after iteration can you make your body efficient for that. The thousandth burpee you do in your life is going to be much more calorically efficient than the first.
Something similar happens with systems: we tend to design the system that covers all cases and automates everything, but this is not possible; First you have to do your business process manually, inefficiently, and naively. This will transform you enough to understand how to automate it in a useful way.
Although today more than ever it seems that code is disposable, one knows that code in production is a liability: every line, every file, every service, every cog in the system you design, can become a problem later down the road. So, all parties are guilty until proven guilty, and there is no greater satisfaction than having shielded components or services that you know are very solid and bug-free.
That hardening, being able to reach a polished and useful product, takes a lot of work. The difficult thing has never been the code, it’s the iterations you have to put into it. You have a finite amount of energy, time and opportunities. Don’t try to get everything from one shot. Try to get out quickly with something manual where it will require a lot of work, and understand where the latent demand is. If there is one, if you are lucky enough to have one, build towards it.
Armored systems. And not only armored in the sense of having secure code. Shielded as important logical business units. Because, well, something that you will learn very quickly is that with a Turing Complete language you can write any set of instructions that you can think of, but that set of instructions may not make any sense. So don’t be confused, because just because you can put something in code doesn’t mean it’s correct.