FOUNDER NOTE
Why every technical founder should understand their production stack
Not so you can do everything yourself. So you can tell the difference between a two-hour problem and a two-week one while somebody is telling you it is fine.
There is a version of technical founder that stops writing code early and manages instead. There is another that keeps their hands in everything and becomes the bottleneck.
The useful position is in between, and the thing that puts you there is understanding your production stack well enough to judge it — not well enough to build all of it yourself.
The point is estimation, not implementation
You do not need to be able to configure the load balancer. You need to know whether "we should move to a different database" is a weekend or a quarter.
That judgement is what lets you push back on an estimate that is too long, accept one that sounds too long but is not, and recognise when someone is proposing a rewrite because they are bored rather than because it is necessary.
Without it you are choosing between deferring to whoever spoke last and guessing. Both are expensive.
The three that cause the worst days
DNS. Every founder eventually has a DNS incident, and they are unusually bad because propagation means you cannot simply undo. Understanding records, TTLs and what a nameserver change actually does takes an afternoon and saves a much worse one.
Authentication. The place where a mistake is a breach rather than a bug. You do not have to implement it, but you should understand where sessions live, what your token lifetimes are, and what happens when someone's account is compromised.
The database. Where the data actually is, what the backup story is, and — crucially — whether anyone has ever tested a restore. An untested backup is a belief, not a backup.
Know how a request reaches your code
Genuinely: from a browser to a response. DNS, TLS, CDN or edge, your application, the database, back.
Most performance and reliability conversations become tractable once you can place a problem on that path. Without the map, you are reasoning about a system you cannot picture, and every explanation sounds equally plausible.
Read your own logs occasionally
Not through a dashboard — the actual logs, on a normal day.
You find out what is failing quietly, what is noisy, and what nobody has looked at in months. It is also the fastest way to discover that a thing everyone assumed was working has been erroring since a deploy in April.
Where I draw the line
I do not do everything. I do not want to. But I want to be able to:
- Explain how a request reaches production
- Deploy and roll back without asking anyone
- Read the logs and the error tracker
- Restore a backup, having tested it
- Understand the auth model well enough to see a hole
- Estimate whether a proposed change is a day or a month
That is a small list and it is enough. The advantage of a technical founder is not writing code faster — it is that there is no translation layer between understanding the problem and being accountable for the decision.