Should we build AI in-house or buy it?

A false binary

"Build or buy" gets framed as if it's a single organisational choice. It isn't. Most organisations end up running a portfolio: some capabilities bought off the shelf, some built in-house, some delivered with a partner and then absorbed. The real question isn't which camp you belong to. It's which capability goes in which bucket, and why.

Get the sorting wrong and you either overpay for a bespoke system that does what a subscription already does, or you hand your differentiation to a vendor and discover later that you've bought yourself out of a competitive advantage.

When to buy

• The capability is a commodity — transcription, translation, OCR, generic chat completion.
• You need it working in weeks, not quarters.
• No differentiation comes from doing it yourself; your customers don't care how you generate the output, only that it's correct and fast.
• The vendor's data handling and contract terms meet your governance bar without heavy negotiation.

Hidden costs: subscription creep as usage scales, integration glue code that nobody owns, and a renewal negotiation you have no leverage in once your process depends on the tool. Vendors also change their pricing tiers and deprecate models with little notice — read the roadmap commitments, not just the current price list.

When to build

• The AI touches something core to your competitive advantage — the thing customers would notice if a competitor couldn't do it.
• You have, or will invest in, data that a vendor can't replicate.
• You need control over the roadmap, latency, or cost curve rather than being at the mercy of someone else's.
• The regulatory risk is high enough that you want the model and its outputs inside your own environment, auditable end to end.

Hidden costs: this is the expensive option, and organisations routinely underestimate by how much. You're not just paying for model calls — you're paying for MLOps, monitoring, retraining cadence, prompt and eval infrastructure, and the salary of someone who understands all of it and doesn't leave. Attrition risk on a small in-house AI team is a real delivery risk, not a footnote.

When to partner

• You need a short-term skills injection while you hire and build internal capability.
• The initiative is high-risk enough that you want a delivery partner with skin in the game, not just an invoice.
• You want to co-design something with a specialist, then take it in-house once it's proven.

Hidden costs: knowledge transfer rarely happens by accident. If the contract doesn't explicitly fund documentation, pairing, and a handover period, the partner leaves with the expertise and you're left with a system nobody in-house fully understands. Specify the handover as a deliverable, not an assumption.

A worked example

A mid-sized insurer runs all three at once. For document OCR and email triage, they bought a commodity vendor tool — it was live in three weeks, and there's no competitive edge in reading PDFs faster than a rival. For claims-fraud detection, they built in-house — it runs on ten years of proprietary claims data no vendor has access to, and a false positive costs real money, so they wanted full control over the model and its explainability. For a customer-facing conversational assistant, they partnered with a specialist agency for the first two releases, with a contract clause requiring the agency to document architecture decisions and pair with two internal engineers — by release three, the insurer's own team owned the roadmap.

Three initiatives, three answers, one portfolio. That's the normal shape of this decision, not the exception.

Pitfalls to watch for

• Buying a commodity tool for something that's actually core to the business, because it was the fast option.
• Building in-house for the sake of "we should have AI capability," with no unique data to justify it.
• Partnering without a defined exit — the relationship becomes permanent because nobody planned the handover.
• Treating the decision as final. Capabilities move between buckets as your data, skills, and competitive position change.

A quick decision heuristic

For each proposed initiative, answer three questions: does this differentiate us, do we have the data, and do we have the skills. Two "yes" answers usually points to build or partner. Two "no" answers usually points to buy. Revisit the answer every six to twelve months — the right bucket for a capability today may not be the right bucket next year.

Next steps

List your current and planned AI initiatives on one page. Score each against the three questions above. Where the answer is unclear, that's the one to discuss with your leadership team before committing budget — not after.

Where Florence helps

Florence's project briefs capture the build/buy/partner decision explicitly for each initiative, alongside the reasoning behind it. That means the decision isn't buried in a Slack thread or someone's memory — it's part of the artefact you can revisit when circumstances change, and it's visible to everyone deciding where the next budget goes.