Who Should Build It

A free puppy is never free. The price of getting one tells you almost nothing about the cost of having one, because the cost lives in everything it needs afterward.

AI has turned internal software into free puppies. A competent engineer with a coding agent can now produce a working AI tool in an afternoon: an assistant that drafts support replies, a bot that summarizes an account before a sales call, a checker that flags odd contract clauses. The demo works, the cost looks like zero, and the obvious conclusion is that building has become cheaper than buying.

Half of that is true. The first version got cheap. Everything after it costs about what it always did.

So "should we build this ourselves?" needs a different answer than it did three years ago. Mine is short: build what encodes your own advantage and will still matter after the next model; rent what someone else will improve for you. "Can we build it?" now gets a yes almost every time, which makes it useless for deciding. "Should we be the ones maintaining this in two years?" still decides.

Where the cost of a tool actually lives

Software engineering has known for decades that the first version is the small part: maintenance takes 40 to 80 percent of what software costs over its life. In a production AI tool, the prompt and the call to the model are a few hundred lines. Everything around them is the rest: checking who the user is and what they may see, connectors to the systems that hold the data, logging, tests, error handling.

AI tools add a kind of maintenance that older software mostly didn't have. The model underneath changes on someone else's schedule. Anthropic, for example, retired Claude Sonnet 4 in June 2026, about a year after its release, and gives at least 60 days' notice before a retirement. Nothing in your code changed, but the world around it did, and each retirement means re-running whatever tests you have, adjusting the instructions, and deploying again.

Then there are the exceptions. A demo runs on the cases its builder thought of. The ones that eat the maintenance budget show up in production: the refund request in an untested language, the customer whose order exists in two systems, the reply that must never promise a delivery date.

The first version is the cheapest part of a tool's life, and it is the only part AI made dramatically cheaper.

One support assistant, traced for two years

To see where the money goes, follow one decision. The numbers are illustrative assumptions for a mid-sized company, not anyone's real quote.

A company has 40 support agents handling 12,000 tickets a month. It wants an assistant that drafts replies and resolves the simplest tickets on its own, say 30 percent of them. Three ways to get there:

• Build. Three engineer-months to go from prototype to production: connecting the ticketing and order systems, permissions, a set of real tickets with known good answers to test against, a security review, a careful rollout. Then half an engineer to keep it running, about five cents of model usage per ticket, and an engineer-month every six months when the model changes.
• Buy. A specialist vendor charging per ticket it resolves. Prices in this category sit around a dollar per resolution; Intercom lists its assistant at $0.99. That is about $3,600 a month here, plus a month of setup.
• Integrate. The helpdesk the company already uses sells an AI add-on at $30 per agent per month. It drafts replies but doesn't resolve tickets by itself, at least for now.

Scroll sideways to see the whole figure

The model accounts for 6 percent. Over two years the built tool costs about $240,000, and 90 percent of that is people: the initial build, the half-time maintainer and three migrations. Most public talk about what AI costs is about the price per token, the small chunk of text a model reads or writes. For an internal tool at this volume, it's the line that matters least.

Now watch month twelve. Suppose the helpdesk ships autonomous resolution at the same dollar per ticket, a reasonable bet in this category. From that day the built tool duplicates a feature the company already pays for, and the question becomes whether it's enough better to justify about $3,600 a month more, counting migrations. Sometimes it is, because it knows the refund rules more precisely or handles quirks of the order system no vendor ever will. Often the company simply bought a one-year head start, and a head start expires the day the vendor ships.

Two things can flip this. Volume is one: the vendor's bill grows with every resolution while the builder's cost is mostly a fixed salary, so in this example building becomes cheaper above roughly 31,000 tickets a month. Value is the other. If a ticket handled by a person costs about $4 of agent time, 3,600 automatic resolutions are worth more each month than any option costs. Then the cheapest option, waiting a year for the helpdesk, becomes the most expensive choice. Once the value is large, the decision turns less on price than on how soon it works and what it costs to leave.

The question to ask before building anything

The single most useful question is this: will a lab or an established vendor ship this, well enough, within a year?

If yes, you are building something with an expiry date. Price it and design it that way.

There is a useful way to see why. The software around a model comes in two kinds (Same Model, Different Results). Scaffolding exists because the model is weak at something today, and it tends to become unnecessary as models improve. Walls encode facts about your organization: who may approve a payment, which system holds the true inventory, what needs an audit trail. Walls matter more as models attempt more.

The same split works for whole tools. A tool that exists because general products can't yet do something is scaffolding at the scale of the company. The companies with tens of millions of users have every incentive to close that gap, and their next release is often aimed at exactly the weakness you're working around. A tool that encodes your refund policy, your approval limits or the judgment of your best underwriter is a wall. Nobody else will build it, because nobody else has what it's made of.

Someone else will likely ship it when it's the same for every company (transcription, meeting notes, document search, generic drafting, code) and sits where the big players already have users: chat apps, office suites, code editors, helpdesks, CRMs. They won't when it depends on data only you hold, when "correct" is defined by your own rules, or when the market is too small to bother.

Jasper is the clearest public example of the wrong side of this test. It sold AI marketing copy built on OpenAI's models and raised $125 million at a $1.5 billion valuation six weeks before ChatGPT launched. The next year brought a cut forecast, layoffs and a lower valuation. A whole market moved, not just one product, but the lesson holds: when your value is access to a general capability, the owner of that capability can offer it directly.

Scroll sideways to see the whole figure

Most real cases land in the top-right corner of that map. A support assistant that answers from your policies is yours in the policies and generic in the language model. So own the rules, the data and the test cases, and rent the model underneath. Then each new model makes your tool better instead of obsolete.

The costs of guessing wrong aren't symmetric either. Rent something nobody improves, and you've paid a vendor's margin for a mediocre tool; you can still build later, knowing much more. Build something the lab then ships, and you lose the build, the maintenance and months of your best people's attention, and you often keep maintaining it because someone now depends on it. Under uncertainty, the option you can reverse is worth more than its price suggests.

The option everyone skips

Most build-or-buy debates skip the cheapest thing to try: switching on the AI in tools you already pay for.

Google folded Gemini into its Workspace business plans in January 2025 and raised their price by about $2 per user per month, so many companies already pay for an assistant whether or not anyone uses it. Helpdesks, CRMs and ERPs add AI features most quarters, and many sit unused because nobody owns the job of turning them on.

What integration brings is easy to undervalue because none of it shows up in a demo. The security review is passed, the data is already there, permissions follow the org chart, and people already know the screens and formats. Each takes weeks to rebuild for something new. Placement matters as much as capability: a slightly better tool outside the CRM, where the sales team spends its day, will be used less than a weaker feature inside it.

The costs are real too. Built-in AI usually trails the specialists, the vendor sets the roadmap, and once AI is bundled into something you can't easily leave, the vendor can reprice it. The Workspace change cut both ways: the feature came included, and the price went up for everyone.

Integration is the default worth beating. Approvals, data and habits come with it.

Who is the right builder

Two centuries ago David Ricardo explained why a country that makes everything more efficiently than its neighbor should still trade: what matters is what else the same effort could produce. Engineering hours work the same way. A team that could build a better support assistant than the vendor still shouldn't, if the same people could be building something only they can. The lawyer who types faster than her assistant still shouldn't do the typing.

The pull toward building has little to do with the merits. Building is visible and satisfying, and coding agents make it feel free; buying means procurement and a contract; maintenance is invisible until it breaks. And the person who builds is often not the person who maintains. An analyst builds a useful tool in a week, moves to another team, and the people left behind inherit a system nobody chose (The Price of Know-how).

The strongest objection deserves a fair hearing: if everyone buys the same assistant, nobody gains an advantage and your team never learns how these systems fail. It holds when the tool is your product or encodes the process customers pay you for. It holds for a team that has never built anything with these systems, because it will judge vendors badly; a small build that's allowed to be thrown away is cheap tuition. As a general rule it fails. Companies didn't win by running their own email servers. Advantage lives in data, distribution, trust and a place in the customer's workflow (Where the Moat Moves).

Own the slow layer, rent the fast

Prices fall, and they also rise, most of all where leaving is hard. After Broadcom bought VMware, AT&T said in a lawsuit that it faced a proposed 1,050 percent increase in its annual bill. And vendors vanish: Builder.ai, once valued above a billion dollars, went insolvent in 2025.

So the test I find most useful fits in one line: if it vanished or quadrupled in price, how long would it take to migrate? Ask it of each layer you depend on, not of the tool as a whole, because the answers differ enormously.

• The model provider can be swapped in days, if you have your own test cases to tell you whether the replacement is good enough and your code talks to the model through one interface. Without those, it takes months, mostly spent discovering what the old model did that nobody wrote down.
• The agent framework takes weeks.
• A vendor application with your workflows built into it takes months.
• The system of record, the database that holds your data and its history, takes quarters or years.

Hence the rule: own the slow layer, rent the fast. Renting the fast layers means someone else pays for their churn. The slow layers hold what is specific to you, and losing control of them costs time you may not have. In the support example, even a fourfold price rise from the vendor after year one would make buying cost about what building would have. That hurts, and it's survivable, provided you can leave.

Three things shorten every migration: your own evaluation set, a few hundred real cases with known good outcomes, so you can test a replacement in a day; data you can take with you, which contracts and, in the EU, the Data Act increasingly protect; and standard interfaces such as MCP, a common way to connect AI applications to tools and data that ChatGPT, Gemini, Microsoft Copilot and others support.

Dependence is unavoidable. The test is whether each dependency sits on a layer you could leave in the time you would have.

What to do

Building earns its cost when the tool encodes your own process, data or judgment; when it's a wall you'll need whatever the model; when nothing adequate exists and you checked; when your volume is past the crossover and someone will own it for life; or when you need to learn and the build is allowed to die. For everything else, my advice is a short routine.

Before any build is approved, write down what the existing stack already offers, including features nobody has switched on, and why it isn't enough.

Ask whether someone will ship it within a year. If yes, rent it, or build it cheaply and plan to throw it away.

Name the owner. Who will maintain this in eighteen months, and is it in that person's job description? If nobody, don't build it. For your own personal tools the rule relaxes: build whatever helps you, as disposable as you like, until someone else depends on it.

Build thin on rented parts. Keep the model behind one interface, keep your test cases current, and write down why each component exists and which weakness it covers, so it can be deleted when a model or vendor closes the gap. A wrong call then costs a quarter instead of a year.

Review at the two moments that force it anyway. At a contract renewal, ask whether something you rented has become important enough to own. At a model release, ask whether something you built is now available, and better, from someone who will keep improving it.

It's a kind of value investing applied to a single tool: compare what you pay with what it's worth, keep a margin for being wrong, and revisit when the facts change. Whether you can build it stopped being interesting the day prototypes became free. Name the person who will be maintaining it in two years, and ask whether they'll be glad it was built.

Check yourself

Why is "can we build it?" no longer a useful question?

The answer is almost always yes, since the first version got cheap. The cost lives in maintaining it, and that is what decides whether you should be the one doing it.

Why does the essay split tools into scaffolding and walls?

A tool that exists because general products can't yet do something will be closed by the labs' next releases. A tool that encodes your own rules, data or judgment is a wall, because nobody else has what it is made of.

Why is renting the less risky mistake when you are unsure?

If you rent something nobody improves, you can still build later knowing more. If you build something the lab then ships, you lose the build, the maintenance and your best people's attention.