Buy, build, or partner

Once a company has decided AI matters and picked something worth doing, the next question is always the same: do we buy this, build it ourselves, or bring in someone?

It's the right instinct and the wrong shape. Asked as one decision for the whole program, it produces a bad answer regardless of which option wins, because AI work isn't one thing. It's a stack, and the correct choice is different at every layer. The companies that get this wrong don't get it wrong by picking the inferior path — they get it wrong by picking one path for everything.

The old rule still applies, but the layers moved

The durable version of this decision has always been: buy the commodity, build the differentiator. That rule is fine. What's confusing about AI right now is that the layers have moved recently and dramatically, so people's instinct about which is which is calibrated to 2023.

The model layer is a commodity, and you should never build it. Nobody outside a handful of labs should be training foundation models, and in 2026 that includes fine-tuning as a first move far more often than people expect — capable general models plus good retrieval and good prompting beat a fine-tune on most business tasks, at a fraction of the cost and with none of the maintenance. Rent this layer. Stay portable, because it re-prices downward every few months.

The generic-workflow layer is increasingly buyable. Meeting transcription and notes, document OCR, contract review, coding assistance, support-ticket triage, sales-call analysis. If a job looks essentially the same at your company as at ten thousand others, someone has built a better version of it than you will, and they're amortizing the cost across all those customers. Buy it. Checking whether you're here is simple: could you describe the job without mentioning anything specific about your company? If yes, buy.

The layer in between is where nothing fits, and it's most of the value. Your invoice-matching against your ERP with your approval rules and your supplier quirks. Your intake process, your payer mix, your compliance constraints. This is where the money is — it's where AI actually pays in manufacturing and every other industry we work in — and it's structurally unbuyable, because the specificity is the value. A vendor selling you a generic version of this is selling you something that handles the common path and stalls on the exceptions — which are the part that was expensive.

So the useful question is never "buy, build, or partner." It's: which layer is this, and what does that layer want?

Buy — what it's actually good for

Buying is underrated by technical teams and it's the right answer more often than they'd like. It's fastest, the vendor absorbs maintenance and model churn, and the cost is predictable.

It works when the job is genuinely generic, when you can live with the vendor's workflow rather than fighting it, and when the integration surface is small.

It fails in two specific ways, both worth naming. First, the exception problem: the vendor handles the common path, your exceptions are the expensive part, and so you buy a tool and keep the team that was working around it. Second — and this one is chronically underweighted — your system-of-record vendor is probably shipping this in eighteen months. Your ERP, EHR, or CRM vendor has your data and a large incentive. Sometimes waiting is correct. The way to decide is arithmetic, not faith: what does the current process cost you over those eighteen months, and does that exceed the cost of solving it now and throwing it away later? Often it doesn't, and the disciplined move is to wait and say so out loud.

There's a variant of buying that's often the actual best answer at Phase 0: adopt the AI features already inside the software you own. They're mediocre and they're free, and they'll teach you which jobs are worth real investment.

Build — what it's actually good for

Building internally is the only path that ends with the capability living inside your company, and for anything that is genuinely your differentiation, it's where you should end up.

It works when the job is core to how you compete, when the process will keep changing so you need to keep changing the system, and — the condition people skip — when you can actually staff it. That last one deserves a plain number: two senior engineers who can do this work well cost most companies well over half a million dollars a year fully loaded, and a mid-market manufacturer or health system is bidding for them against labs and AI-native startups offering equity and more interesting problems. Hiring, ramping, and retaining that team is a nine-to-twelve month project that runs before your first system ships.

It also fails in a way that's specific and expensive: the first internal build pays full tuition. Your team will learn about eval harnesses, exception design, retrieval quality, and cost control by getting them wrong on your highest-profile project, and there's no discount for it being a learning experience. That's not an argument against building. It's an argument about sequencing — which is where the third path earns its place.

Partner — what it's actually good for

Bring in an outside team when you need capability or capacity you don't have, on a timeline that doesn't allow for growing it first. Concretely, that's four situations.

The first one or two systems. Someone who has shipped these before knows where the effort actually goes — integration, evaluation, exception design — because they've paid the tuition already. The value isn't that they're smarter than your engineers; it's that they've made the mistakes elsewhere.

The last mile specifically. Plenty of companies have prototypes and no production systems. That gap is where most companies stall, and it's mostly not model work — it's writing into a decades-old ERP with an audit trail compliance will accept, building the benchmark, designing the escalation. It's unglamorous, it's the majority of the engineering, and it's a well-defined thing to hire for.

The shared layer, once you have two systems that need one. Identity, data access, evaluation, observability, deployment. Getting this architecture right is what makes your fourth project cheap, and it's the highest-consequence set of decisions in the whole program.

Firepower and depth alongside a team that's already good. Not every engagement fills a capability gap. Plenty of companies have strong engineers and a real AI function and still bring people in — because the roadmap is bigger than the team, or because one project needs depth the team hasn't built yet: a robotics stack, a plant floor, a claims pipeline, an eval harness for a domain where correctness is subtle. This is the embedded version of the work, and it's worth distinguishing from the body shop below: you're buying senior people with specific experience who pair with yours, not undifferentiated hands. The test is whether your team is better at this after the engagement than before. If the answer is no, you hired the wrong shape.

Partnering fails in three predictable ways, and every one of them is detectable early. It fails when there's no internal owner — a partner with no counterpart on the operating side builds something nobody adopts, and no amount of engineering quality fixes that. It fails when the partner is used as a body shop — you rent hands, you get velocity and no capability, and you're back here next year. And it fails when the engagement has no transfer built in: if nobody on your team can maintain, extend, or reason about the system when the engagement ends, you didn't buy a capability, you bought a dependency with a support contract.

That last point is worth being direct about, since we're the ones writing this: a partner whose incentive is to remain necessary will build a system only they can operate. Ask, in the first meeting, what your team will be able to do without them in six months, and ask what documentation and handover look like. The answer to that question sorts the field faster than any technical evaluation.

Where we'd tell you not to hire us

Some of these are more useful than the sales pitch, so here they are plainly.

You want a build and you don't have a named job yet. If you can't name a specific, repeated job and put a number on what it costs you today, then a build is the wrong purchase — not because you're not ready to work with anyone, but because you'd be paying to construct something before anyone knows what it should be. What that situation needs is a scoping pass: a week, not a quarter, ending in one job with the evidence attached. We run those, and the inputs have to come from your operation rather than from us — your objective, your constraints, your baseline numbers. What should worry you is anyone quoting a build before that question is settled.

The job is genuinely generic. If what you want is meeting notes, or transcription, or document OCR, buy the product. Paying a firm to build it is paying more for less.

You need generic capacity, not specific depth. If you have a strong team and what's actually missing is more hands for ordinary work, staff augmentation is cheaper than we are and you should use it. The premium is only worth paying when the gap is specific — AI systems your team hasn't built before, or a domain where the hard-won knowledge is the thing you're buying.

Nobody in the operating org will own the outcome. If the only sponsor is IT or innovation and no billing manager, purchasing lead, or supervisor will put their name against a number, the project will not survive contact with month three. Fix that first; it costs nothing and it's the highest-return thing on this page.

You want to be told AI will cut 30% of headcount next quarter. Somebody will tell you that. It won't be us, and it won't be true.

The answer is usually layered, and it has an order

For most companies with a real operation and no AI engineering function, the sequence that works looks like this: rent the models, buy anything generic, partner on the first system and on the shared layer that comes out of it, and build the second and third yourself using that layer — with your partner's team progressively less involved by design.

That sequence is deliberately structured to end with the capability inside your company, because that's the only end state that compounds. An outside team is how you get through the transitions faster than you could alone.

If you already have an engineering and AI function, the shape is different rather than absent. You're not buying a sequence, you're buying depth on specific projects — a domain your team hasn't worked in, a roadmap wider than your headcount, a system where getting the evaluation right is the hard part. That's a long-running relationship rather than a handover, and it stays healthy as long as the same test holds: your people should be better at this because of the engagement, not more dependent on it.