Technology strategy and economics
Sooner or later an architect is asked a question with money in it. Should we build our own search or buy a service? Is this vendor's lock-in acceptable? Why are we adopting a new database when the old one works? Answering well needs a few economic tools (total cost of ownership, lock-in seen as an option, Wardley maps) and a way to write the answers down so a hundred engineers make the same call without asking: an engineering strategy.
1. The idea
Build, buy or adopt open source
| Option | Choose it when | The cost people forget |
|---|---|---|
| Build | It's how you compete, nothing on the market fits, or the market is immature | People to maintain it for as long as it lives |
| Buy (a product or a managed service) | The need is common, a mature product exists, and you can live with its model | Integration, price rises with volume, and the cost of leaving |
| Adopt open source | A healthy project solves it and you want control over where it runs | Running, patching and upgrading it yourself; a project that loses its maintainers |
Total cost of ownership
Compare options by their total cost of ownership (TCO) over the system's likely life, usually three to five years, not by their first-year price:
| Cost | Examples |
|---|---|
| Acquire | Licences, the first build, the initial integration |
| Run | Infrastructure, subscription fees as volume grows, support contracts |
| People | Engineers to maintain, operate and upgrade it; training; on-call |
| Change | Major upgrades, forced migrations, keeping up with security fixes |
| Exit | Moving the data and the integrations out if you have to leave |
The hidden term is opportunity cost: an engineer maintaining a home-grown search engine is not building the feature that wins customers.
Lock-in is the price of an option
Gregor Hohpe's point: lock-in is not yes-or-no, and avoiding one kind usually buys another. Writing everything against a portable abstraction to avoid a cloud provider locks you into the abstraction, costs effort now, and gives up the provider's best features. Treat it as a purchase: the expected cost of switching later (how likely, times how expensive) against the cost of staying portable now. Pay for portability where switching is realistic; accept lock-in where the managed service is worth it.
Wardley maps
Simon Wardley's maps put each component of a business on two axes: up and down, how visible it is to the user (the value chain, from the user's need down to infrastructure); left to right, how evolved it is:
| Stage | What it looks like | Usual choice |
|---|---|---|
| Genesis | New, uncertain, changing weekly | Build, experiment |
| Custom-built | Understood by a few; each company builds its own | Build if it's your edge |
| Product (and rental) | Several vendors sell it; features converge | Buy |
| Commodity (and utility) | Standard, priced per use | Rent; never build |
Components move right over time as markets mature, so a good build decision can become a bad one. The map makes that movement, and where you are spending engineers, visible to everyone.
Choose boring technology
Dan McKinley's essay gives each company a few innovation tokens, "maybe three" early on. Every new database, language or framework spends one, because its failure modes are unknown and someone must learn to run it. Spend tokens where they buy an advantage; use well-understood technology everywhere else.
Writing an engineering strategy
A strategy turns repeated decisions into one written answer. Will Larson's Crafting Engineering Strategy (2025) builds one in five steps:
- Explore how others have solved the problem.
- Diagnose your own situation before proposing anything.
- Refine the thinking: model it, map it, test it against real cases.
- Policy: the rules and the trade-offs they accept, with the reasons.
- Operations: the mechanisms that make the policy happen: review checklists, templates, fitness functions.
His shortcut for getting started: write five design documents, then read them together and write down the decisions that kept coming up. A strategy without reasons is a rule people will route around.
2. How it works
A grocery delivery company's map, three years apart
The company maps what its customers need and what it takes to deliver it. Watch what the map decides, and what happens when one component evolves.
Five design docs become a strategy
Four recent design documents each spent weeks on the same argument: can Redis hold data that must not be lost? Watch the argument become a policy.
3. Try it yourself
Build or buy product search?
An online shop needs product search. Build it on open-source search software and run it yourselves, or buy a hosted search service. Set the effort, the price and the time horizon, and say whether search is how this shop competes.
Assumed figures, to show the shape: an engineer costs $250,000 a year with overheads. Building adds $60,000 a year of infrastructure; maintenance starts in year 2. Buying needs 3 person-months of integration and a quarter of an engineer each year; the price rises 20% a year with volume, and leaving would cost about $150,000 of migration work.
4. Trade-offs
Control vs focus
Building gives exact fit and full control, and spends engineers on something customers may not notice. Buying keeps the team on what makes the business different, inside someone else's roadmap.
Portability vs leverage
Staying portable keeps the option to leave and costs effort and features now. Using a provider's managed services fully is faster and cheaper until you need to move.
New vs boring
A new technology may fit the problem better; a familiar one has known failure modes, people who can run it, and answers on the internet. Spend innovation tokens deliberately.
Strategy vs autonomy
A written strategy saves every team the same argument and narrows their choices. Write policies only for decisions that keep recurring and are costly to get wrong, and say how to ask for an exception.
5. In real projects
Put the comparison in a table the business can read. Each option's five-year TCO, the people it ties up, its exit cost, and its effect on the top characteristics (Module 06). Then record the decision as an ADR (Module 27), including what would make you revisit it.
Revisit on a schedule. Markets evolve: the component you built three years ago may now be a product with five vendors, or a cloud service priced per use. A yearly look at the map catches the moment to stop building.
Keep strategies short and specific. One page per decision area ("Where durable data lives", "When we use managed services"), each with its diagnosis, policy, exceptions process and an owner. Link them from the design-doc template so authors see them before they write.
Larger organisations set standards across many systems; see Module 33's strategies for how much to standardise.
Say it in the interview
- "Build or buy?" Build what differentiates the business and isn't available; buy what's a mature product; rent what's a commodity. Compare five-year total cost including the people who maintain it and the cost of leaving.
- "How do you think about vendor lock-in?" As an option with a price: the chance we'll need to switch times the cost of switching, against the cost of staying portable now. I pay for portability only where switching is realistic.
- "Why not use the newest database?" Every new technology spends one of a few innovation tokens: unknown failure modes and new skills to run it. I'd spend one only where it buys a real advantage.
- Comparing licence prices and ignoring the engineers a build ties up.
- "We'll abstract the cloud away" with no estimate of what it costs.
- A new technology chosen because the team wants to learn it.
6. Remember it
How this hook works: what "build your edge, buy the rest" means
What the slogan means, phrase by phrase
- "Build your edge"
- Custom-build the few components that are genesis or custom-built on the Wardley map and that customers choose you for.
- "buy the rest"
- Products and commodities: buy or rent them, judged on total cost of ownership and accepted lock-in.
Why this picture fits: it's the furnishing decision: have the kitchen made only if the kitchen is why people come; buy the wardrobe; never make light bulbs.
The story → the concept
| Furnishing a flat | Technology economics |
|---|---|
| The carpenter's kitchen | A custom build of your differentiator |
| Flat-pack units | A bought product: integration work, then it works |
| Renting furnished | A managed service priced per use |
| Light bulbs | Commodities nobody should build |
| The cost of moving out | Exit cost and lock-in |
The trap it saves you from
A team that maintains its own message queue, deployment tool and search engine, and has no one left to build the product.
7. Common mistakes
8. Design exercise (30 minutes)
- Map it (10 min). Draw a Wardley map of a product you know: the user's need at the top, six to eight components below, each placed by evolution.
- Find one mismatch (10 min). Mark one component you build that the market now sells, or one you rent that is really your edge. Estimate its five-year TCO both ways.
- Write one policy (10 min). Pick a decision your teams keep arguing about. Write a one-page strategy: diagnosis, policy, how to ask for an exception, and one mechanism that makes it stick.
9. Self-check quiz
Which costs are most often missing from a build-or-buy comparison?
On a Wardley map, a component sits in the commodity stage. What's the usual choice?
How should lock-in be weighed?
In "Choose boring technology", what is an innovation token?
In Larson's steps, what comes before writing any policy?
10. Go deeper
| Resource | Time | Why |
|---|---|---|
| The components of an engineering strategy (Will Larson) | 20 min | Explore, diagnose, refine, policy and operations, from Crafting Engineering Strategy. |
| Writing an engineering strategy (StaffEng) | 15 min | Write five design docs, then synthesise them. |
| Don't get locked up into avoiding lock-in (Gregor Hohpe) | 25 min | Lock-in as an option, with a model for deciding. |
| Choose Boring Technology (Dan McKinley) | 20 min | Innovation tokens. |
| Learn Wardley Mapping | 30 min | Value chains, evolution and how to read a map. |