Tech Tuesdays: Why You Should Think Twice Before Prioritizing “Good” Technical Decision Making
Kendrick Taylor is the software lead at Sano Intelligence, a digital health company that is making an API for the blood stream using a hardware and software platform that does continuous blood chemistry monitoring. He has a BS in computer science from James Madison University.
There are a million ways your early stage startup can fail, and prioritizing “good” technical decisions is high on the list.
“Good” is bad, and “great” is worse when it comes to early technical decisions. You need to get to market as fast as possible and to do that you have to fight every instinct you have to make something scalable, maintainable, distributed, or high performing. This is a good time to point out that, no, I’m not terrible at my job. I promise.
Your only job early in a startup is to build something and get it in front of people as fast as possible. It turns out that technical decisions, early on, don’t matter as much as you think they do. Later, once you have customers, they may matter a great deal, but they never matter less than before you have customers, or a product. My advice is choose whatever you work fastest in, and build in that. Forget scale, forget recruiting, forget speed, forget elegance. Build a product, and circle back on those things when they matter.
Any technology stack you pick, running on one server, will get you to through to “success”. Success in this context is either profitability, or the ability to raise large sums of money. Success matters because it will give you the resources to fix your technical problems.
You might ask: “Why not focus on making good decisions, and avoid problems down the road?”
It’s because good decisions take a lot of time. You wind up spending time asking yourself questions like: “What’s the network latency on AWS?”; “Is this an atomic operation?”; “How many servers do I need for high availability and how should I load balance them?”; “How do I make sure I have zero downtime?”; “How do I shard over multiple data centers?”; “Is my cache invalidating properly?”; and so on.
Every “good” technical decision you prioritize, or even entertain, costs you time and resources. This is problematic because building a startup is about allocating time and resources when both are scarce. Focusing on making “good” technical decisions is a bad allocation of resources because you’re solving for problems you might have in the future, not the problems you have now.
The problems you have now are on the order of “we don’t have a product”, not “we have too many users”. If you get to “we have too many users”, you’re probably sleeping on a pile of VC money, and you can pay for scale. Spending months building for a problem you don’t have also means you throw all that work away if you pivot.
The other problem with obsessing over “good” technical decisions is that your customers don’t care about your technology choices. They don’t move the needle at all.
You also might ask: “What about availability? If my product crashes we’ll get a bad reputation.”
Good enough is good enough in the early days of a startup. When you have a reputation, you’ll have customers, and when you have customers you’ll have resources, and when you have resources you’ll have myriad options to solve your technical problems. Successful startups make these technical pivots all the time.
You can change your technology: FourSquare changed from MySQL to Postgres to MongoDB, Twitter moved from MySQL to Cassandra.
You can improve the technology you’re using: Facebook built it’s own PHP interpreter, then built a compiler that turns PHP into C++.
You can invent new technology: Facebook built Cassandra and Tornado among other projects. Google invented MapReduce, and modern data center design.
Remember the fail whale. Twitter cracked under load every day for months. Want valuations like Twitter? Follow their lead.