The build-vs-buy question for AI is asked badly. The usual framing — "we want to control our IP, so we should build it ourselves" or "consultants are faster, so we should hire them" — treats it as a values question. It's actually a five-question diagnostic. The honest answer is sometimes "consultant," sometimes "in-house," and sometimes "neither yet."
Five questions. The answers point you to the right shape of engagement before you start interviewing vendors or hiring engineers.
1. Have you shipped a production AI system before?
Not a demo. Not a prototype. A system that real users depend on, that has an eval set wired into CI, that has a cost cap, that has a named operator. If the answer is no, the gap is expertise. The first system is the most expensive one to learn on; everything you do wrong, you'll do wrong with high blast radius.
This is where consulting makes the most economic sense. The consultant's first system is your fifteenth, even if it's your first — they bring the patterns that took someone else two years and three failures to learn.
If the answer is yes, the question shifts to volume.
2. How many workflows are on the roadmap?
One workflow doesn't justify hiring a team. Ten does. The threshold is typically around three to five — below that, the marginal cost of adding consulting capacity is lower than the fixed cost of standing up an internal AI team with the right hiring, tooling, and governance.
If the roadmap shows three workflows over eighteen months, hire a consultant for the first, then evaluate. If it shows ten over twelve months, start hiring now — the throughput required will exceed what an external team can sustain at a price you'll tolerate.
3. Is the AI capability core to a product you sell, or core to how you operate?
If a customer is buying the AI behavior — your product is the model's output — the capability needs to be defensible, ownable, and continuously improved. That's an in-house build, even if it starts with consulting help.
If you're using AI to operate the business better — internal workflows, productivity, automation — consulting can carry it indefinitely. The behavior doesn't need to be uniquely yours; it needs to be reliably yours.
4. How fast does the first workflow need to ship?
If the answer is "this quarter," consulting almost always wins. An external team can start Monday with a known method; an in-house team needs to be hired, ramped, and tooled before it does productive work, which typically takes two to four months.
If the answer is "within the year," in-house is feasible. If "within two years," in-house is the right structural choice — you'll spend the consulting money on the same expertise you're hiring anyway.
5. Who will operate the system after launch?
This is the question most engagements skip and most regret. The handoff is the product. A system without a named internal operator is a depreciating asset from day one — no one updates the eval set, no one watches the cost trend, no one fields the question when an output looks wrong.
If the answer to "who runs this in six months?" is unclear, neither consulting nor in-house is the right answer yet. Fix the staffing question first. The build is cheap; the operating capacity is the hard part.
The three failure modes
Failure mode 1: buying a build with no operator
You hire a consultant. They ship a system. They leave. There's no one internally who owns the eval set, the cost cap, or the quarterly review. Six months later the model provider updates silently, accuracy degrades, and no one notices until a customer complains. The fix is naming the operator before the engagement starts, not at handoff.
Failure mode 2: hiring an in-house team for one workflow
You hire two AI engineers and a domain analyst. They ship the first workflow in nine months — slower than a consultant would have. Then there's no second or third workflow ready to start, and the team's utilization drops to thirty percent. Within a year, the team is being scrutinized for its ROI. The fix is committing to the workflow pipeline before committing to the headcount.
Failure mode 3: starting in-house from a too-ambitious first workflow
The team's first attempt requires hard evaluation, hard governance, and hard human-in-the-loop design simultaneously. It takes eighteen months and ships something fragile. Two engineers leave during the project. The fix is picking a first workflow where at least one of those three dimensions is trivial — typically by choosing a workflow with a tolerant failure mode, an obvious ground truth, or batch (rather than real-time) operation.
The honest version
For most SMBs in regulated industries with one to three production workflows on the near-term roadmap and no prior AI shipping experience, hiring a consultant for the first system and using that engagement to train an internal owner is the highest-EV path.
For SMBs with five or more workflows on the eighteen-month roadmap and a sponsor willing to commit to the headcount, hiring in-house and bringing in a consultant for specific subject-matter help (eval set design, governance, model selection) on each workflow tends to outperform either pure approach.
For everyone else, the right answer is "not yet" — close out the staffing and roadmap questions before deciding the structure.