Technology
Architecture, platform, and technical judgment.
Which technical decisions deserve your attention, which ones you should refuse to make yet, and how to keep the system cheap to change.
Architecture decisions that age well
Write down the decision, the alternatives you rejected, and the conditions that would make you revisit it. Future you is a stranger with no context.
5-20 · 20-50 · 50-150 · 150+
Build, buy, or borrow
There's no default rule worth having here. Three tests decide it: is this what customers pay us for, who carries it at 3am, and what does it cost to get out.
0-5 · 5-20 · 20-50 · 50-150 · 150+
Tech debt as a balance sheet, not a feeling
Debt is the gap between the system you have and the one your roadmap needs. Price it against specific upcoming work and pay it inside that work, never in a scheduled debt sprint.
5-20 · 20-50 · 50-150 · 150+
The monolith you should probably keep
A service is earned when a workload's operating characteristics genuinely diverge and a specific team can own that failure domain. Not at a headcount threshold, and never because the codebase feels large. Most of the time what you actually want is a stateless monolith.
5-20 · 20-50 · 50-150
The data model is destiny
You can refactor code in an afternoon. A wrong core entity outlives three rewrites and quietly decides what your product is allowed to become.
0-5 · 5-20 · 20-50 · 50-150 · 150+
Boring technology, deliberately chosen
You get a small number of innovation tokens. Spend them where your product is actually differentiated and buy the rest off the shelf.
0-5 · 5-20 · 20-50 · 50-150 · 150+