Software Architecture in the AI & Cloud Era

← the whole book on one page

Chapter 13: Buy, Build, and the Economics of Dependence

Build what makes you different; buy what makes you the same.

Look back over the road we have traveled and you will find that every earlier chapter has made this decision at least once, usually without stopping to call it by name. Chapter 1 handed payments to a provider, because no fan buys a ticket from Encore for the way it moves money. Chapter 3 told us to buy the generic subdomains and put the best people on the core. Chapter 11 said to own less by default, and Chapter 12 weighed hosting a model ourselves against renting one through a vendor’s application programming interface (API). The decision keeps coming back for a reason. I have come to believe it is the most consequential choice an architect makes, and it is one we make over and over again, every time a new need appears. Until now this book has treated it in asides, a sentence here and a paragraph there. This chapter gives it the attention it deserves.

The question is far older than the cloud. At the 1968 NATO software engineering conference, Doug McIlroy argued for an industry of mass-produced software components. His hope was that programmers might one day assemble systems from parts already made, the way an engineer orders standard bolts from a catalog, instead of writing every routine afresh. Nearly two decades later Brooks, in “No Silver Bullet” (Chapter 1), named buying as the most radical attack on software’s essential difficulty. His reasoning was simple: the cheapest program to build is the one we never build at all, because every line we do not write is a line we never have to design, test, debug or maintain. Neither idea is new, then. What has changed since is the menu. There are far more things on offer than McIlroy could have imagined, and the vendors, prices and positions on that menu now shift quickly, so an answer that was right a few years ago may quietly have become wrong.

To see what this means in practice, consider Encore’s queue for one quarter, which holds four of these decisions. The first is whether to replace the homegrown catalog search with a search product, or keep tuning what it has. The second is whether to adopt a fraud-detection vendor, or keep Bot Screening in-house. The third is whether to host an open-weights model for the support assistant (a model whose trained parameters are published, so Encore could run it on its own machines), or stay on the vendor’s API. The fourth is a status page, and Encore will buy one, obviously. But that word “obviously” is where the interesting work begins: the useful question is not only what to decide, but which decisions are obvious, and why they are, so that we can spend our deliberation where it matters. Answering well takes four things, and they set the order of this chapter: a vocabulary for the options, a map of how their timing changes, a full ledger of what each one costs, and a process for deciding that outlasts a hallway argument.

13.1 The Decision Space

We usually talk about this choice as “build versus buy,” and the phrase does quiet damage before the discussion even starts. It offers two doors when there are really several, and the most useful options are the ones it hides in between. I count at least four. What separates them is easiest to see if we track two quantities for each one: what we own, meaning the parts of the system whose behavior and future are ours to decide, and what we owe, meaning the work, money and trust we must keep paying to have it. The two pull in opposite directions: we want to own as much as possible and owe as little as possible, but the more we own, the more we owe in upkeep, and the only way to owe less upkeep is to own less.

Read the table from top to bottom and a pattern appears. Each step from build toward rent trades some control for some relief. We own less of the system’s future, because more of its roadmap is set by someone else. We owe less of its upkeep, because someone else patches, upgrades and operates it. And the kind of thing we owe changes, from labor toward trust. When Encore builds, it pays in engineers’ hours. When it rents, it pays a subscription and trusts the vendor to stay solvent, stay secure, and keep the product pointed somewhere useful.

That trust has a name in this chapter. Dependence, as we will use the word, is the condition in which part of our system’s behavior, cost or future is decided by someone we do not employ. It is tempting to think that building is the way to escape it, but none of the four options does. Even a homegrown system depends on the people who built it staying around, and a service written by one engineer who then leaves is a dependence on someone Encore no longer employs. So the question is never whether to depend. The four options differ in whom we depend on, and on what terms.

Economists reached this question long before we did. In “The Nature of the Firm” (1937), Ronald Coase asked why companies make some things themselves and buy others on the open market. If markets are efficient, why have firms at all? His answer turned on the costs of transacting: finding a suitable supplier, negotiating terms with it, and enforcing the agreement once it is signed. When those costs are high, it is cheaper to do the work in-house; when they are low, it is cheaper to buy. Software has its own versions of each. Finding and negotiating become integration, the work of fitting a product into our system. Enforcing becomes governance, the work of watching the vendor’s behavior, security and pricing over time. And software adds a third that weighs especially heavily: exit, the cost of leaving when the relationship sours. These three are exactly the costs that build-versus-buy debates tend to leave out, because they appear neither on the vendor’s price sheet nor in the team’s build estimate.

So how do we choose among the four? The first filter is Chapter 3’s differentiation test, which asks whether a capability is a reason customers choose us. A capability that makes Encore win, such as fair on-sale admission or bot resistance, deserves ownership. Owning it is the point: it is where Encore’s advantage lives, and handing it to a vendor would hand that advantage to every competitor who buys from the same vendor. A capability that everyone needs and no customer picks Encore for, such as authentication, email, payments or status pages, deserves the thinnest commitment available. Encore must do these well, but doing them unusually well wins no fans.

A band makes the same distinction without thinking about it. It writes its own songs, because the songs are why anyone comes to the show, and it rents the PA system, because no fan ever bought a ticket for the cabling. The analogy is worth taking one step further, though, because that is where it breaks. A PA system is cleanly separable from the music: swap one rig for another and the song is the same song. Software’s parts are rarely that separable. A rented component carries its own data model, its own limits and its own release schedule, and these press on everything built around it. A rented search engine, for instance, decides what queries fans can express and how results are ranked, which shapes the product far more than any amplifier shapes a song. So the sorting is clean only at the ends. The hard cases sit in the middle: capabilities that matter to the business but do not set Encore apart, where all four options are genuinely in competition.

Let us run Encore’s queue for the quarter through the filter, one item at a time. Bot Screening is core, so Encore keeps building it. But “build” here does not mean building every layer. The build can sit on top of a purchase: Encore rents commodity bot signals at the edge, such as device reputation scores and lists of known-bad networks, and owns the fairness policy that turns those signals into admission decisions. Any vendor can tell Encore that a request comes from a suspicious network; only Encore decides what that means for a fan’s place in the on-sale queue. This is a lesson in itself. The four options are not mutually exclusive; they compose, layer on layer, and the layer worth owning is usually the thin one on top, where the judgment lives.

The other items sort quickly or not at all. The status page is generic, so Encore rents one. Catalog search matters, since fans who cannot find the show cannot buy the ticket, but nobody chooses Encore for its search box, so it lands in the middle. The AI stack lands in the middle twice: once for the model itself, and again for everything around it, the evals, rate limits and serving platform that make a model useful to the support assistant. Notice what the filter did and did not do. It decided none of these questions. What it did was sort them by how much deliberation each deserves, so that the status page needs little thought while catalog search and the AI stack get the careful analysis the rest of this chapter provides.

Recap. Build, adopt, buy and rent are points on a scale that trades what we own against what we owe, and as we move toward rent, what we owe shifts from labor to trust. None of the four escapes dependence; they differ in whom we depend on and on what terms. The differentiation test sorts capabilities into those we should own, those we should rent, and a middle that deserves real deliberation, and the options can be layered so that we own only the thin layer where our judgment lives.

Exercise 13.1. List the last five capability decisions your organization made, whether consciously or by default (a library someone added, a service a team signed up for). For each one, write down which of the four options it landed on, and whether anyone applied a differentiation test before deciding.

13.2 Evolution and the Map

The differentiation test from Section 13.1 is a photograph: it tells us where a capability stands today. Capabilities, however, do not stand still. Simon Wardley observed that every capability travels the same road, in a predictable direction, though not at a predictable speed, and Chapter 15 will apply his idea to whole platforms. The road has four stages:

• Genesis. The capability is novel and experimental. A few people are trying it, nobody yet knows the right way to do it, and nobody sells it.
• Custom. The capability is understood well enough to build on purpose, but there is still nothing to buy, so the organizations that need it build their own by hand.
• Product. Enough people need the same thing that vendors appear and compete with one another, mostly by adding items to their feature checklists.
• Commodity. The capability has become standard and undifferentiated. Every supplier’s version is good enough, it is priced per unit, and it is boring, which is exactly what we want from it.

Each stage rewards a different posture, meaning a different stance toward the capability. At genesis we build, because nobody sells it yet; at custom we build or adopt, but only where the capability differentiates us; at product we buy and let the vendors compete; at commodity we rent, pay per unit and stop thinking about it. The catch is that the posture which wins at one stage loses at the next. The capability keeps moving even when we do not, so a decision that was right when we made it can become wrong years later without anyone touching a line of code.

Figure 13.1 — The evolution road from genesis to commodity, with the winning posture at each stage. The failure mode is posture lag: still hand-building what became a product years ago, or renting what should differentiate you.

Electricity traveled this road, and its journey shows how the movement happens. Early industrial factories often ran their own generating plants, not out of any love for dynamos, but because there was no reliable alternative: if a factory wanted power, it made its own. Once the electrical grid matured, the same private plant became an expense with no advantage, since the factory’s products were no better for having been made with homemade current. The analogy holds for the direction of travel. It breaks on interfaces. One utility’s kilowatt-hour is interchangeable with another’s, so switching suppliers changes nothing on the factory floor. A software product, by contrast, arrives with its own data model, its own API and its own opinions about how work should be done, and our code grows around all three. So even a software commodity is rarely as fungible as current in a wire, which is why leaving one carries the costs we examine in Section 13.4.

If capabilities move along this road, two consequences follow for the decisions we make about them. The first is that decisions have expiry dates. Consider a company that built its own API gateway in 2015. At the time this was a reasonable custom-stage decision: the need was clear, and the products on offer were immature. In the years that followed, competing gateway products matured, and the capability moved into product territory. The code did not change, but its meaning did: what had been sensible engineering became posture lag. We can define posture lag as the gap between the stage a capability has actually reached and the stage our posture toward it still assumes. The 2015 gateway’s owners were still acting as if gateways were a custom-stage capability long after the market had moved on.

Posture lag is hard to see from inside, and the reason is worth understanding. The team maintaining the old gateway is doing real work, fixing real bugs and shipping real improvements, so the system still looks like an asset on every status report. The work also still feels like craftsmanship, because it is skilled and done with care. What nobody sees from inside is that the same skill could be spent on something that differentiates the company, because that comparison never appears in anyone’s day. The remedy is to decide when to look again at the moment we make the decision, while the reasoning is fresh. So we write the expiry into the architecture decision record (ADR), the short document that records what we decided and why: for a custom-built capability, something like “revisit when two credible products exist.” The future team then inherits not only the decision but the condition under which it stops being true.

The second consequence is that new capabilities appear on top of old commodities. Each capability that becomes a commodity turns into the floor on which the next genesis is built, much as cheap, standardized electricity made possible a wave of appliances that nobody could have built while every factory made its own power. Large language model (LLM) inference is a current example. Serving an LLM is still a custom-stage capability: the techniques are understood, but organizations are still assembling and tuning their own setups. Yet it runs on commodity compute, the rented processors and graphics processing units (GPUs) that every cloud sells by the hour. That combination is why a hosting decision many teams thought was settled for good, “we rent everything from the cloud,” is open again: a new capability has arrived above the commodity, and its own position on the road is still moving. Encore faces exactly this in its question about the support assistant’s model. The map does not make the decision for us. What it does is tell us when a decision we thought was finished has started to move again, and that is the moment to reopen it.

Now the map can settle Encore’s search question, which the differentiation test in Section 13.1 left in the middle. Search engines reached the product stage a decade ago, and purpose-built search products now compete with one another. Encore’s catalog search is an index that two engineers tune by hand. A vendor whose whole business is search will outpace it on features and on upkeep, because the vendor spreads that work across many customers while Encore pays for all of it alone. So the posture that fits the product stage is to buy.

Buying, though, is not free, and the map does not pretend otherwise. Three costs remain with Encore. First, the purchased search index must be kept in sync with Encore’s catalog, so that a newly announced concert, or a show that has sold out, appears correctly in results. Second, relevance tuning for Encore’s own domain still needs one engineer’s ongoing attention: a fan who misspells an artist’s name, or types a band whose name has an unusual spelling, still has to find the right show, and no vendor knows Encore’s artists out of the box. Third, Encore needs an exit, so the product sits behind Encore’s own search interface, and Encore’s other services call that interface rather than the vendor directly, which keeps a future switch of vendor contained. With those costs counted, Encore buys the product, keeps one engineer on relevance, and moves the other to the on-sale, where the work does differentiate Encore.

Recap. Capabilities travel from genesis through custom and product to commodity, and the posture that wins changes at each stage, from building to building-or-adopting to buying to renting. Because the capability moves even when our decision does not, every decision carries an expiry date that guards against posture lag. New capabilities keep appearing on top of old commodities, and the map tells us when a settled decision has started to move and needs revisiting.

Exercise 13.2. Place your organization’s five biggest homegrown systems on the evolution road, marking for each whether it sits at genesis, custom, product or commodity today. For any that sit in product or commodity territory, name what keeping them costs per year, counting the engineers who maintain them and anything else the upkeep consumes.

13.3 The Economics of Build and Buy

The map tells us when to revisit a decision; the ledger tells us what each option really costs. Both sides of that ledger tend to be underestimated, and in characteristically different ways. Build estimates run low because teams price the construction and forget the ownership. Construction is the part we can see and plan: the design, the sprints, the launch. Ownership is everything that follows for as long as the system runs: fixing defects, upgrading dependencies, adapting to new requirements, keeping it secure and keeping it up. Robert Glass’s widely cited estimate puts maintenance at 40% to 80% of software cost, about 60% on average. Read that the other way round and it says that the project plan, which is where most estimates stop, covers, on average, only about 40% of what the system will cost us. Worse, the larger share arrives after the builders have moved on to other work, so the people who made the estimate are rarely the people who pay it.

Why should software in use keep costing so much, when a finished building mostly just stands there? Meir Lehman gave the answer a name. He began by studying the growth of IBM’s OS/360, and in the 1970s he formulated what became known as the laws of software evolution. The first of them says that a program in use must be continually adapted, or it becomes progressively less useful. The reason is that the world around the program keeps moving: users want new things, regulations change, the operating system and libraries underneath are upgraded, and the systems it talks to change their interfaces. A program that stays still while all of that moves drifts out of fit with its surroundings, a little more each year. So software in service is less like a finished bridge, which we build once and inspect occasionally, than like a garden, which begins to decline in the very season we stop tending it. Encore’s homegrown catalog search, from Section 13.2, is a fair example: every new artist name, every new way fans misspell one, and every change to the catalog’s shape is work someone must do just to keep the search box as good as it was. This is why I think of every system we build as a pension we have promised to pay: a small decision today, followed by a payment every year for as long as the system lives.

Then come the quieter costs, the ones that never appear on an invoice. The first is opportunity cost. Our best engineers tend to end up maintaining whatever we build, so every hour they spend on undifferentiated work (work that keeps Encore running but gives no fan a reason to choose it) is an hour not spent on fair on-sales or bot resistance. The second is concentration of knowledge. Engineers call this the bus factor: the number of people who would have to be lost, to a bus or simply to a better offer, before nobody understands the system any more. A system that only three people understand has a bus factor of three, and it shrinks each time one of them changes teams. The third is hiring. A stack that nobody else runs is a stack nobody arrives already knowing, so every new hire must learn it from scratch, from the few people who still remember why it was built that way. None of this says we cannot build. A competent team can build nearly anything. The real question is whether we want to still be paying for it in year six, when the excitement of the launch is long gone and the pension payments are not.

Buy estimates run low too, but for different reasons. The first is integration. A vendor’s demo shows the product working on its own, and integration is never the demo. To put a product into Encore, someone has to connect it to Encore’s identity system, so the right people and services can use it; wire up the data flows in both directions; decide what happens when the product is slow or down; and reconcile every place where the product’s model of the world meets ours. If Encore buys the search product from Section 13.2, for instance, the product has its own idea of what a “document” is, and someone must translate Encore’s concerts, venues and artists into that idea, and keep the translation in sync every time the catalog changes. The second is lock-in, which accumulates quietly with each of those connections and gets a section of its own (Section 13.4). The third is that the commercial terms do not stay put. Prices tend to rise once we have integrated, because the vendor knows leaving is now expensive. And vendors get acquired, retire products, or fold, on their schedule rather than ours.

So the buy-side ADR needs a line that enthusiasm usually leaves out: the exit plan. It answers two questions. What leaves with us when we go: our data, our configuration, and the operational know-how we built up running the product? And how long would leaving take: days, weeks, or a year? The cheapest way to keep that answer short is Chapter 3’s anticorruption layer (ACL), and this is where it earns its keep. The ACL is a translation layer between our code and the vendor’s: our core speaks only Encore’s own terms, and the ACL converts them into the vendor’s API and back. This is Parnas’s criterion from Chapter 1 applied to a contract. Parnas taught us to hide behind a module boundary the decision most likely to change; here the decision most likely to change is which vendor we use. With the vendor’s model confined to one layer, the vendor’s concepts stay out of our core, and switching vendors means rewriting one translation layer rather than hunting through every place the vendor’s API had spread. For the search purchase, that layer is Encore’s own search interface, which is exactly the exit Section 13.2 named.

Open source sits on the middle path between building and buying, and I have spent a decade on its far side, as a maintainer. MockK, the mocking library I maintain (Chapter 7), is other people’s adopt decision. When a team adds MockK to its build, it gets a mocking library with no license fee, no vendor to negotiate with, and the option to fork the code if the project ever goes somewhere they cannot follow. It also gets something that no contract names: a dependency on one maintainer’s weekends. If that maintainer is busy, tired or gone, the fix the team needs may simply not come. Good adoption budgets for that risk in three ways. Pin versions, so that an upgrade happens when we choose to make it rather than when a release lands. Track the project’s health as you would a vendor’s balance sheet, because a project losing its maintainers is a supplier going quietly out of business. And contribute fixes upstream. That is partly good citizenship, but it is also the cheapest insurance in software: a fix we send upstream is one the project now maintains for us, and an engineer who has worked in the codebase is someone who can carry it if the maintainers ever cannot.

Open source has a second risk, which is that its license can change. Elasticsearch, Terraform, and Redis were all relicensed away from open-source licenses, which left their users facing terms they had not chosen. In each case the community forked the last open version (OpenSearch, OpenTofu, and Valkey) and that fork became the exit. The lesson is to note who owns the copyright before adopting. A project whose copyright is spread across many contributors is hard to relicense, because everyone would have to agree. A project owned by a single vendor can change its terms in a release note.

Whichever ledger we are keeping, both need due diligence, and the checks are different for each. For code we adopt, keep a software bill of materials (SBOM): an inventory of every component and version our systems depend on, so that when a vulnerability is announced we can tell in minutes whether Encore is affected rather than spending days finding out. Then watch each project’s health signals: how regularly it releases, how many people maintain it, and its Open Source Security Foundation (OpenSSF) Scorecard, an automated rating of a project’s security practices. For vendors, read their security attestations (a SOC 2 report or equivalent, in which an independent auditor assesses the vendor’s security controls) before signing, because a vendor we have integrated is part of our system, and when it is breached the breach becomes our incident.

AI coding assistants have changed one side of this ledger and barely touched the other. They have made construction markedly cheaper, so “we could build this in a sprint” is truer than it used to be. They do far less for ownership: the on-call rotation, the upgrades, the security patches, and the one person who understands why the design is the way it is. Follow the arithmetic through. Ownership already accounts for most of a system’s cost. If construction gets cheaper and ownership does not, ownership becomes an even larger share of the total, so the year-six question matters more than it did, not less. It also becomes easier to say yes to a build, because the visible cost has shrunk while the invisible cost has stayed where it was. Code has become cheap to write; it has not become cheap to keep.

Recap. Building is priced at construction but paid for in ownership, because software in use must keep adapting to a changing world. Buying is priced at the subscription but paid for in integration and, eventually, in exit. Open source trades a license fee for a dependency on its maintainers and its license. So every buy-side ADR carries an exit plan, and every adoption budgets for the maintainer’s weekends.

Exercise 13.3. Take one system your team built more than three years ago. Estimate what fraction of its lifetime cost so far was the initial build, and what fraction has been ownership since. Would you build it again today, and if not, what is the exit plan?

13.4 Lock-In and the Special Cases

Every purchase in Section 13.3 left us a little more dependent on someone else, and that dependence has a name: lock-in. It is tempting to treat lock-in as a sin to be avoided at any price, but that framing helps nobody, because any useful dependency locks us in to some degree. A better habit is to treat lock-in as a cost, one we can estimate before we buy, just as we estimate the subscription. The useful question is not “are we locked in?” but “what would it cost to open the lock, and how long would it take?” Lock-in also comes in several distinct kinds, each held shut by a different mechanism, and each with its own way out:

Read down the Escape column and a pattern appears: almost every escape is cheap when we take it early and expensive when we take it late. Consider an export pipeline that copies Encore’s data out of a vendor’s system every night in an open format. Built on day one, it costs a few days of engineering, and nobody gives it a second thought. Built during a pricing dispute, it costs a quarter of work, done under pressure, while the vendor knows we are trying to leave and has every reason to make that slow, so we negotiate from weakness. The reason the late version is so much worse is that lock-in accumulates quietly. It settles like sediment in a river: each new integration, each new dataset, each feature built on a vendor-specific API deposits a thin layer. No single layer is worth worrying about, so nobody watches the riverbed rise, until the day a boat runs aground on it.

So far this chapter has leaned toward buying whatever is not core. There are, however, three cases in which building wins even after the lock-in has been priced in. The first is when the capability is the differentiation. Nobody buys their core, because the thing customers choose us for cannot also be the thing every competitor can rent; for Encore, that is why Bot Screening’s fairness policy stays in-house. The second is when the terms are unacceptable and no vendor will change them. Regulated data is the usual example: if the law says certain records must stay in a particular place or under particular controls, and no vendor offers a compliant home for them, then there is nothing to buy. The third is scale. When we rent, part of every invoice is the vendor’s margin, the profit on top of what the service costs them to run. At small volumes that margin is a bargain, because it pays for expertise we would otherwise have to hire. At very large volumes, though, the margin alone can exceed what it would cost to employ a team of our own to run the same thing, and at that point building becomes cheaper. This is the logic behind the repatriation stories the industry likes to retell, of companies moving workloads out of the public cloud and back into their own data centers. Those stories are real, but they are rare, because most companies never reach the volume where the arithmetic flips. The lesson is not to copy them; it is to run your own numbers.

The AI stack is where all of this is being tested right now, and it is one of the four decisions in Encore’s queue: stay on a rented model API for the support assistant, or host an open-weights model ourselves. Each side buys something and charges for it. Renting the model API buys frontier quality, the best models available, with none of the work of serving them. The price is charged per token, so it grows in a straight line with traffic: twice the support conversations, twice the bill. Renting also raises a data-governance question, since fans’ messages and order details travel to the provider. And renting does not hand over everything: we still own the evals that tell us whether the answers are good, the rate limits we must design around, and the model retirements, which arrive on the provider’s schedule rather than ours. Hosting open weights, a model whose parameters are published so anyone can run it, buys the opposite set of properties. We get control over the model and its upgrades, data residency because the fans’ data never leaves our infrastructure, and a flatter cost curve, because, up to the capacity of the hardware we have bought, it costs much the same whether it handles a thousand conversations or a hundred thousand. The price is graphics processing units (GPUs) that we pay for whether or not they are busy, an inference platform that someone on our team must operate, and a model that usually trails the frontier.

How do we choose between them? The arithmetic is the one the time-sharing era of Chapter 11 taught. Renting wins while use is occasional, because we pay only for what we use and someone else absorbs the idle time; owning wins once the machine would be kept busy, because then the fixed cost is spread over enough work to undercut the rental price. So the crossover depends on utilization, how much of the time the hardware would actually be working. That gives us a practical sorting rule. Steady, high-volume, narrow workloads can justify hosting: classifying every incoming support message by topic, say, runs all day, at a predictable rate, on a task a smaller open model handles well. Workloads that are spiky, or that depend on the very best quality, rarely can. The hard minority of requests that Chapter 12’s router sends to frontier models is both: it arrives unpredictably, so hosted GPUs would sit idle between bursts, and it needs exactly the quality that open models lag on.

One more consideration argues for caution whichever way the AI decision goes: the market is moving unusually fast. Model serving is turning from a custom capability into a commodity, with better tools, cheaper hardware and new providers arriving all the time, so a choice that is right today may be wrong within the year. That argues for thin commitments, such as short contracts, no large up-front hardware purchases, and the AI gateway of Chapter 12 between our code and any provider, together with revisit dates measured in quarters rather than years. In a market moving this quickly, I have come to think the most valuable property of a decision is how cheaply it can be undone.

Recap. Lock-in is a cost to measure before we buy, not a sin to avoid at all costs. It comes in six kinds (data gravity, interface, egress, skills, contract and behavioral), each with its own escape, and most escapes are cheapest when taken early, before the sediment builds up. Building still wins in three cases: when the capability is our differentiation, when no vendor offers acceptable terms, and when our scale makes the vendor’s margin larger than the cost of our own team. The AI stack follows the time-sharing arithmetic, where utilization decides between renting and hosting, and because the market is moving so fast, it calls for thin commitments revisited quarterly.

Exercise 13.4. For your most important vendor dependency, write the exit plan that does not yet exist. List what leaves with you (data, configuration, know-how), name the interface it leaves through (an export, an API, your own ACL), and estimate how many weeks the move would take. Then say which of the six kinds of lock-in would hurt most if you had to leave tomorrow, and why.

13.5 Running the Decision

We now have the vocabulary, the map and the two ledgers. What remains is the process that turns them into a decision the organization actually keeps. The first step is to write it down, because a decision that exists only in a meeting does not outlast that meeting: the people leave the room, memories drift apart, and six months later nobody can say what was agreed or why. So we record it as an ADR, as this book has done since Chapter 1, and for buy-versus-build decisions we make two sections mandatory. The first is the exit plan, because dependence without an exit is surrender: if we cannot say how we would leave, we have handed the vendor every future negotiation. The second is the expiry date, because capabilities keep moving along the evolution road (Section 13.2), and a decision that was right this year can drift into posture lag without anyone touching it. The expiry date is the alarm that tells us to look again.

In some industries the exit plan is not merely good practice but a legal duty. The EU’s Digital Operational Resilience Act (DORA), in force for financial entities since January 2025, requires documented exit strategies for information and communication technology (ICT) providers that support critical functions. Encore is not a bank, but the regulation is worth noticing for what it reveals: once a regulator has watched enough institutions find themselves unable to leave a supplier, it stops treating the exit plan as optional. The rest of us can learn that lesson more cheaply.

Before the decision is written, it has to be made, and the evaluation that informs it needs a fence around it. We run it as a proof of concept with a calendar and explicit success criteria agreed in advance. Suppose Encore evaluates a search product this way: a fixed number of weeks, a sample of real catalog data, and criteria written down on day one, such as whether misspelled artist names still find the right show. When the calendar runs out, the team compares the results against the criteria and decides. Without that fence, an evaluation tends to drift into a shadow project: a half-integrated product that nobody chose, quietly accumulating the very lock-in the evaluation was meant to weigh.

How much deliberation a decision deserves depends on how hard it would be to undo, so we score reversibility first and spend our care in proportion. Consider Encore’s two extremes. A rented status page is a revolving door: if the product disappoints, Encore can walk out through the same door it came in, swapping to another provider in days with almost nothing left behind. A data platform is a one-way gate: once years of orders, fans and events live in its formats and every service reads from it, going back is a migration measured in quarters, with real risk to the data itself. The status page deserves an afternoon; the data platform deserves the full map, both ledgers and a hard look at the exit plan. Spending the same effort on both would be wasteful in one case and reckless in the other.

These decisions are also political, and pretending otherwise is how good analyses die in committee. They are political because they move budgets, headcount and pride: a team that built a system may see its retirement as a judgment on its work, and a manager may see a smaller team. I once led the retirement of a home-built API gateway in favor of a market product. The map made the call obvious in an afternoon. Making it real took a chief product and technology officer’s sign-off, four architecture-board sessions, and a year of engineering alongside the teams, including tens of thousands of lines of integration and Kubernetes-operator code before the old gateway could be switched off. The gap between the afternoon and the year is the lesson. Retiring a system is a construction project of its own, with its own design, its own risks and its own staffing needs, and it deserves to be planned and staffed as one rather than squeezed in between feature work.

Nobody defended the old gateway on its merits. People defended what it represented: work they were proud of, expertise they held, and a decision that had been right when it was made. That last point deserves respect, because posture lag is rarely anyone’s mistake. It is what a good decision becomes when the world moves and the decision does not; the engineers who built the gateway had chosen well for their time, and the market had simply caught up with them. So calling the gateway bad would have lost the argument, because it would have told its builders that their past judgment was wrong, and they would rightly have refused to hear it. What won the argument was evidence that blamed no one: the evolution map, showing where API gateways now sat on the road; the maintenance ledger, showing what keeping ours cost each year; and an exit plan, showing that the move could be made safely. We presented these patiently, to every audience. Nor was buying the end of the work. It traded undifferentiated maintenance for integration, which is a better trade but still a trade, and the exit plan stays on file in case that trade ever turns against us.

Recap. Record every buy-versus-build decision as an ADR with two mandatory sections: an exit plan, so the dependence never becomes surrender, and an expiry date, so the decision is revisited as the capability moves along the evolution road. Run the evaluation as a time-boxed proof of concept with success criteria fixed in advance, and spend deliberation in proportion to how hard the choice would be to reverse. Expect the decision to be political, plan the retirement of the old system as a project in its own right, and argue with the map and the ledger rather than with people’s past work.

Exercise 13.5. Pick a buy-versus-build decision your organization is currently avoiding, and draft a one-page ADR for it that includes the two mandatory sections: an exit plan (which data and code you would take with you, through which interface, and how long leaving would take) and an expiry date (the condition or date that should trigger a revisit). Then answer two questions in a short paragraph each: whose pride does this decision threaten, and what does the evolution map say to them?

Kata: Compass

Your brief: “Compass.” Compass is a 40-engineer logistics startup that routes same-day deliveries in three cities. Four capabilities are on this quarter’s decision list. Authentication is homegrown, passwords and all. Package search for the support team runs on SQL LIKE queries, the kind that scan a table for a matching fragment of text. Payments go through one processor, hardcoded into the application. Route optimization is the thing customers actually pay for: it runs on the founder’s algorithm, which beats every vendor Compass has benchmarked. The chief technology officer has set one constraint: “we can staff exactly one build.” Three of the four capabilities will therefore be bought, adopted or rented, and one will get the engineers.

Deliverables:

1. Evolution map — place all four capabilities on the road from genesis to commodity (Section 13.2), and state the posture that fits each position: build, adopt, buy or rent.
2. The ledger — for each capability, set the full cost of building against the full cost of buying, in order-of-magnitude numbers. The build side counts construction and ownership, meaning the years of upkeep after the first release. The buy side counts integration and exit, meaning what it would take to leave the vendor later.
3. Four ADRs — one per capability, each with the two mandatory sections from Section 13.5: an exit plan and an expiry date.
4. The one build — name the capability that gets the staffing, and defend the choice against the differentiation test: does owning this capability make Compass win?

Rubric:

Where you now stand

You can now sort capabilities by whether they differentiate, time each decision with the evolution map, keep both ledgers honest, and run the decision as a process that ends in an ADR with an exit plan and an expiry date. Throughout this chapter, Encore has been the buyer, deciding what to own and what to rent. Meanwhile, venues have started asking to run their own Encore, which puts Encore on the other side of the table: its product would become the thing another organization weighs in its own buy-versus-build decision. Selling into that decision needs an architecture of its own. Many customers share one system, so each venue’s data and load must be kept isolated from the others; customers of different sizes need different tiers of service; and the cost each one generates must be attributed to it. Chapter 14 builds that architecture: multi-tenant SaaS.

References

• Gregor Hohpe — Cloud Strategy. Leanpub, 2020.
• Robert L. Glass — Facts and Fallacies of Software Engineering. Addison-Wesley, 2002.
• Eben Hewitt — Technology Strategy Patterns. O’Reilly, 2018.
• Simon Wardley — Wardley Maps — free online.
• Martin Fowler — Utility vs Strategic Dichotomy — free online.