Build, buy, or bring someone in: deciding on AI

An AI capability can be built, bought, or handed to someone who sets it up and leaves it with you. Most leaders frame the question as binary, in-house or outside, and pick the wrong frame. The real question is not who does the work. It is what you want to own at the end. Here is how I decide with my clients when the call has to be made.

Three routes, not two

• Buy SaaS: a vendor has already built the block, you switch it on and pay per use. Fast and predictable, but you take the product as it is.
• Hire: you build an in-house AI team. You own the skill, provided you can recruit it, manage it, and keep it.
• Bring in an external specialist: someone who starts fast, puts the capability in place, then hands it over to your teams without settling into the furniture.

What an in-house AI team really costs

Hiring is the most appealing route on paper: the skill stays with you. It is also the slowest and most expensive to get running, and it is almost always underestimated. None of what follows is an argument against hiring. It is an argument for only launching it once you know precisely what you want to build, and why it deserves a permanent team.

• Time: between writing the job, recruiting a rare profile, and getting them up to speed on your context, count on months before the first production release.
• Headcount: one good AI engineer alone is rarely enough. You need data, integration, operations. A team, not a person.
• Oversight: someone has to be able to judge the work and settle technical calls. If no one in-house can, you are hiring blind.
• Retention: these profiles are in demand. Training them and then watching them leave means starting over.

What SaaS solves, and what it never will

SaaS is the right answer when your need is ordinary, in the good sense: transcription, translation, text generation, a standard support assistant. Someone has already built it better than you would, and maintains it. Switching it on in days rather than building it over months is almost always the right call, on one condition: watch the bill. I have seen AI budgets drop by 30 to 70% on an audited LLM bill, at equal quality, simply by putting the right tool back on the right job. Auditing and cutting that cost is often what makes an AI capability sustainable over time.

• Your own process: SaaS encodes the average process of its market, not yours. Where your work is specific, the generic tool stalls.
• Your data: depending on the vendor, it passes through and sometimes rests on their servers. For a sensitive or regulated case, that is not neutral.
• Integration: wiring the tool into your CRM, your ERP, and your files is work the subscription does not do for you.
• Lock-in: the deeper SaaS sits inside a process, the more it costs to leave, and the per-use price never falls on its own.

The role of an external specialist: start, transfer, don't settle in

This is the route I work in, so let me be direct. A well-scoped external specialist does, in a few weeks, what a fledgling team takes months to put in place. That is where the independent model differs from the big consultancy: no interest in dragging things out, a method built around transfer from day one. You still have to pick the right one, which is a subject of its own: I wrote how to vet an AI provider for that.

• Start: I arrive with the use cases already seen elsewhere, the known traps, and proven building blocks. No learning curve to fund.
• Transfer: the goal is not to stay. I document, I train your teams, I leave a system they can run and evolve without me.
• No dependency: the deliverable is not just the system, it is your ability to keep it alive.

A good external specialist is measured by what they leave you the day they walk out, not by how long they stay.

The decision grid

• Your maturity: can you describe the need precisely, and is your data usable? If not, none of the three routes will hold before that work is done. That is the whole point of checking whether your data is ready for AI.
• The stakes: is this a competitive edge you want to own, or a commodity that just has to work? You do not build what you can buy, and you do not buy what makes your difference.
• Data sensitivity: the more critical or regulated your data, the more you need control over where it lives. That points to in-house or to custom software hosted on your side, not to mass-market SaaS.

The neither-one-nor-the-other trap

Cross those three axes and the answer almost always takes shape. The worst choice, though, is none of the three: the soft middle. A half in-house project handed to someone who already has another job, with no dedicated time or skill, sitting on a SaaS nobody ever really scoped. It moves for six months, ships nothing solid, and ends up costing the price of a real team for the result of a patch job. The cause is simple: someone wanted to avoid deciding. Deciding costs a little up front. Not deciding costs a lot later, with nothing to show.

A realistic hybrid model

• Buy the commodity: anything ordinary and non-differentiating runs on proven SaaS. You do not spend your energy there.
• Build what sets you apart: where it is your edge, you invest, with an external specialist who starts and transfers rather than a team assembled in a rush.
• Keep a small in-house hand: one or two people who understand the whole, can steer providers, and keep what was delivered alive. Stewardship, not a factory.
• Bet on open standards: connecting your tools through a standard like MCP, adopted by Anthropic, OpenAI, Google and Microsoft and handed to the Linux Foundation in late 2025, keeps you free to swap a block without redoing everything.

None of these routes is good in the abstract. The right one depends on your maturity, your stakes, and your data, and it shifts over time. If you are unsure which is yours, let's talk through your case: an hour is often enough to see clearly what to buy, what to build, and where to start.