Build vs. buy AI

Buying AI is priced per person. Building it is priced per use. 2 pieces of AI work at the same company can land on opposite sides of that line in the same month, and the difference decides more than any comparison of features will.

4 tiers sit between the 2 ends: an off-the-shelf subscription, an industry tool with AI already inside, an assembly of a model and the company’s own systems, and a custom build. Most companies sit at the wrong one for the work they are doing.

Per person, or per use

Buying is priced per seat. The bill is the number of people times the monthly price, and it does not move when the work does. Hire 10 people and it goes up. Have a busy quarter and it does not. The person who opens the tool twice a month costs the same as the person who lives in it.

Building is priced per use. There are no seats. Each time the work runs, the system sends a request to a model and gets billed for that request, so the bill tracks how much work went through it. What that meter counts, and how to estimate it before building anything, is the chapter before this one. A month where nothing runs costs close to nothing. 10 times the volume costs roughly 10 times as much. Underneath that sits the cost of building the thing once, which does not repeat.

Those are 2 different counts, not 2 ends of one scale. Buying is priced by how many people touch the work. Building is priced by how often it runs. Work that scores high on one count usually scores low on the other, so work spread thinly across many people usually favours buying, and work that repeats constantly, done by a few people or run unattended, usually favours building.

Business tiers of the major assistants sit in the tens of dollars per person per month, in the same band as the other per-seat software a company already pays for, with heavier usage tiers several times that. That figure has moved in both directions more than once. The shape has not: a per-person line that grows with the company.

Neither count is the whole bill. Buying adds the time people spend learning the tool. Building adds the engineering to make it and the checking afterwards, and where a person reads every output before it goes anywhere, that reading time is often larger than the model bill it is checking.

Example

Let’s say Northwind Industrial, the 200-person distributor from how to find where AI can help, has 2 AI decisions on the table in the same month. One is whether to pay for an AI assistant for everyone who works there. The other is what to do about order-status questions, which are most of what support answers all day and have already passed the fit screen. They look like one decision about how much to spend on AI.

The 2 counts put them on opposite sides. An assistant for everyone is 200 seats whether or not the warehouse supervisor ever opens it: at tens of dollars a seat that is thousands of dollars every month, and it stays there. The order-status tool has no seats at all. One lookup and one short reply costs a fraction of a cent, so its 4,800 questions a month are a bill in the tens of dollars. They are not competing options. They are 2 different pieces of work, and each picks its own side.

The off-the-shelf tier

ChatGPT, Claude.ai, Gemini, Copilot, Notion AI, Cursor. Sign-up-and-use products, mostly on a subscription, sometimes free.

They are for individual work: drafts, research, code, conversations. Anyone on the team can be using one within 5 minutes, which makes this the only tier where the first working version takes minutes.

The tier fits while the work is generic and does not need to know anything specific about the company’s data or workflow, and while the person prompting is also the person reading the output. Nothing runs unattended. It is also the cheapest way to learn what AI does to a kind of work before deciding what to build around it.

It runs out when the model needs to know things about the business that are not in its training, like customer records, internal documents or pricing rules. That kind of grounding is the job of tools and memory. It runs out when the work has to sit inside a system, triggered by an event, connected to other tools, running unattended. And it runs out when audit logs and access controls stop being optional (where your data goes covers what each surface implies).

Most companies under-invest here, for a simple reason: the seat price is visible on an invoice and what it buys is not. What sits on the other side of that line is the slow drafts getting faster, the research that used to take an afternoon taking 20 minutes, and the first honest read anyone in the company gets on what AI does with their own work. That read is worth the seats on its own, because it is the cheapest way to find out which of the other tiers the company actually needs.

The industry-tool tier

Tools built for one job in one industry, with AI inside. Sales tools that handle outreach. Support tools that draft ticket replies. Recruiting platforms that screen CVs. Vendors call this vertical SaaS: software sold as a subscription, built for one industry rather than for everyone. Hundreds of them, more every week.

They are for a specific repeated workflow where the vendor has already done the connecting work, written the prompts and handled the odd cases. When the fit is real, months of wiring are already done.

Getting one live takes weeks, and most of those weeks go on connecting the tool to the company’s systems and cleaning up the data it will read, not on the tool itself. Weeks is also where it stops. What the vendor saves is not the wait. It is the connectors and the odd cases, already built and already tested against other customers, which a custom build spends months on after it first works.

The market here is genuinely uneven. Some of it is excellent and saves months. Some is a thin layer over a general model at premium pricing. The test is not the marketing. It is whether the product does meaningfully more than a smart prompt on a generic tool would do.

4 things a real one holds that a prompt does not. The connections to other systems, already built and kept working as those systems change underneath. A data model that has already survived a few thousand other customers’ odd cases. Testing the vendor has run against real inputs at a volume no single company can reach on its own. And handling for the failures nobody thinks of at demo time, like the record with 2 owners or the attachment that arrives as a photograph of a page. A product holding those 4 is worth paying for. A product holding none of them is a prompt with a login page, dressed in industry vocabulary, glossy on the standard case and broken at the edges where actual operations live.

What gets stranded when a subscription ends is more than the data export. The prompts the vendor tuned over 2 years, the connection someone in IT built once and will now build again, the history the team’s judgement is calibrated against, and the way the team has reorganised itself around the tool’s shape. That last one is the expensive part and the one nobody prices.

The assembly tier

Between buying a finished product and building a system from scratch sits the tier most mid-sized companies actually land in. Automation platforms like Zapier, Make and n8n, and the agent builders now inside the major AI products, connect a model to the company’s systems through configuration rather than code.

The person doing this is usually not an engineer. It is whoever already owns the workflow and is comfortable writing a spreadsheet formula. The first working version takes days.

This tier fits when the work is specific to the company but the pieces are standard: a trigger, a lookup, a model call, a person who checks, a destination. It runs out when the logic gets deep enough that a configuration screen is harder to reason about than code would be, when the per-run charges start to bite at volume, or when something runs unattended and needs handling for failures nobody can express in a form.

Its pricing sits between the 2 lines: a subscription with a charge per run on top, so it grows with usage but has a floor underneath it.

Example

Let’s say an enquiry form comes in from the website. The platform reads it, looks up the account in the CRM, asks a model for a draft reply, and puts the draft in a queue for someone to check before it goes out. The person who set that up runs the support team and has never written code. It took 2 days.

The custom build tier

This tier reaches past the products to the platform layer, where the model providers sell access to the model itself for software to call rather than for a person to type into. That means GPT, Claude or Gemini sitting behind the company’s own code, its own data and its own screens, or a model the company runs on its own servers. The result is a system that exists nowhere else, because the workflow it serves exists nowhere else.

Who writes that code is a separate question from whether to build. Some companies build with the developers they already have, some hire one, some bring in an outside team, and the tier is the same either way. What changes with the answer is who understands the system a year later.

The tier fits when the workflow is central to how the business runs and part of how it competes, when the data and processes are specific enough that no off-the-shelf vendor would model them well and probably never will, and when ownership matters enough that the code, prompts, data and connections have to stay in-house rather than depend on what another company decides to build next. The volume has to justify the cost of building it: a workflow that runs a hundred times a day for years pays back differently from one that runs 10 times a quarter.

It does not fit when the workflow is generic and an off-the-shelf tool already handles it, when the reason is that the company should be doing AI rather than that this work demands it, or when nobody inside the company is going to own the system after the project ends.

The first working version takes weeks rather than days, and a finished one takes months rather than weeks, because the connectors and the odd cases an industry tool arrives with all have to be built here. What makes a good AI project is about the shape those months take.

Custom build sits at the bottom of the stack: most flexible, most expensive to start, most demanding of people inside the company. It is where the most distinctive work happens, and where the most money gets burned when the work did not need to be there. Its running cost is metered by use, which is the one thing about it that surprises people: a system that succeeds gets more expensive as it succeeds. The exception is running the model on the company’s own machines, where the bill is the capacity rather than the requests. That one is flat every month, and only comes out cheaper at volumes in the millions of requests.

How the tiers stack

The tiers are not a ladder where everyone climbs. They are a stack, and most companies should sit on several layers at once. Broad off-the-shelf access for the team. A few well-chosen industry tools for repeated workflows that fit a vendor’s shape. Assembly for the work that is specific to the company but built from standard pieces. A custom build reserved for the small number of workflows the business actually competes on.

2 mistakes recur. The first is building custom for generic work, which spends months and a budget to arrive at something worse than a product that could have been switched on in a week. The second is paying premium prices for an industry tool that turns out to be a thin layer over a model, which leaves the team inside a workflow it did not design and cannot change.

Example

Let’s say a founder hears about AI and scopes a 6-month build for a workflow ChatGPT handles as it comes. 6 months and a budget later, the sales team is using an internal tool that is worse than the off-the-shelf product they could have rolled out in a week.

Now say a leader at another company signs a 5-figure annual contract for a recruiting tool sold on a demo. Once it is live, the screening summaries read like a general chatbot in recruiting vocabulary, the connection to the applicant system never quite works, and the team cannot change the steps to match how it actually hires.

Both are the same error read from opposite ends: the tier was chosen on what the work felt like rather than on how many people touch it and how often it runs. With those 2 counts on the table, the tier usually picks itself.