Wardley Mapping: Know What to Build, Buy, and Let Commoditize
I wrote recently about using Cynefin to decide how to approach a system — best practice, expert analysis, experimentation, or immediate action. Wardley Mapping, Simon Wardley's other contribution to how technologists think, answers a different question that has to come before that one: where should you even be spending engineering effort in the first place?
The mistake it's built to catch is one I see constantly in AI teams right now — custom-building something that's about to become a utility everyone buys by the drink, while under-investing in the one or two things that are genuinely a differentiator.
Two axes, not four quadrants
A Wardley Map plots components on two dimensions: visibility — how close a component is to the end user, from invisible infrastructure to something the customer directly experiences — and evolution — how mature and commoditized that component is, from a one-off experiment (Genesis) through Custom-Built and Product, to Commodity or Utility, where it's interchangeable, cheap, and boring.
That's a rough map of a typical AI product's stack today. It's the shape, not the exact placements, that matters — the point is to actually draw your own for your own system and argue about where the dots go.
The one rule that does most of the work
Everything on a Wardley Map moves left to right over time, pulled by competition, supply and demand, and the fact that once something can be standardized, someone will standardize it and sell it cheaper than you can build it. Nothing moves right to left. That's the whole strategic engine of the map: whatever you're looking at today, ask where it's headed, not just where it sits.
GPU compute and vector databases are already deep in Commodity territory — you rent them by the token or the query, from multiple interchangeable vendors, and arguing about which one to "architect around" is usually wasted motion. LLM inference itself is the fastest-moving dot on most teams' maps right now — priced, benchmarked, and swapped between providers almost as casually as a database connection string, when eighteen months ago it was something people fine-tuned in-house and treated as a core asset.
The teams I see burning the most engineering time are the ones custom-building deep in that commoditizing middle — hand-rolled model-serving infrastructure, bespoke vector index management — while their actual differentiator (the retrieval logic tuned to their specific domain, the agent orchestration that encodes real institutional judgment) gets a fraction of the attention, because it doesn't feel as urgent as standing up infrastructure.
Where this connects back to Cynefin
Wardley has written about this explicitly, and it's the reason these two frameworks pair so well: evolution stage predicts which Cynefin domain a component behaves like. Genesis-stage components are Complex or worse — you can't analyze your way to the right design, only probe and learn, because nobody, including the vendors, fully knows how they'll behave yet. By the time something is a Product, it's mostly Complicated — expert analysis and good practice get you a solid answer. By Commodity, it's Clear — there's a boring best practice and you should simply follow it, because arguing about it is pure waste.
Read that back against a real AI stack: agent orchestration patterns are still genuinely Complex — expect to probe, not to design upfront. LLM inference is sliding from Complicated into Clear faster than most teams' architecture decisions are keeping up with, which is exactly why so many "which model should we build around" debates from two years ago look quaint now. Matching your process to the map, not just to how unfamiliar something feels, is the actual skill.
What I actually do with a map like this
Three things, every time I draw one for a real system: I flag anything sitting in Genesis or Custom-Built that isn't a genuine source of differentiation, and I push to buy or consume it instead of building it — that's engineering time recovered for the one or two things that actually matter. I flag anything I'm treating as "core infrastructure we own" that's visibly sliding toward Commodity, because that's usually a sign of sunk-cost architecture, not strategy. And I redraw the map every couple of quarters, because the single biggest mistake isn't misjudging where something sits today — it's forgetting that the map is a snapshot of a system that's constantly moving right.