Founder engineering
Some engineering decisions belong to the founder whether or not the founder writes code. Not because delegation is wrong, but because these particular choices are expensive to reverse, they shape what the company can do for years, and the cost of getting them wrong lands on the business rather than the codebase.
Build or buy for billing is the clearest example: buying is right far more often than founders assume, but there are four specific moments where a hosted processor quietly stops being enough, and hitting one unprepared turns a planned migration into a scramble. Who owns the code that moves money is another. So is knowing which questions to ask before anyone starts, because source of truth, idempotency, and the audit trail are painful to retrofit once real customers depend on them.
These essays are written for the person accountable for the outcome, in plain language, without pretending the trade-offs are simpler than they are. You do not need to be able to write the code to interrogate the plan. You need to know which answers are specific and which are warnings dressed up as confidence.
- You are deciding whether to build billing or buy a processor.
- You are making your first revenue-critical engineering hire.
- You want to interrogate a technical plan without being the expert.
Why cutting is a step rather than a plan, and what a team loses when the people holding context leave.
What to listen for when hiring the person who will own revenue code, and why boring is the compliment.
The three answers I refuse to start without, and what a good answer to each actually sounds like.
Buy by default, and the four predictable moments (tax, usage pricing, marketplaces, provider limits) that force the question.
The auth decisions that are cheap now and expensive later: session handling, password storage, and token scope.
Weighing one of these decisions right now?
Build vs buy, a first revenue-critical hire, or a plan you want a second opinion on before you commit. Tell me the situation.
Get in touchBuilding something where this kind of work matters?
I'm in GMT+6 and work async-first, so your timezone is never a reason not to reach out.
Get in touch