Buy vs build vs hire: a decision matrix for AI initiatives

The decision is rarely "do we use AI?" by the time we get a call. It's "we've decided AI; now how do we get it done?" Three paths: buy an off-the-shelf SaaS product, build something in-house, or hire a consulting firm to build and hand over.

We do the hire path for a living, so we have an obvious bias. We try to be honest about when one of the other two would have served the client better.

When to buy

Buying off-the-shelf SaaS is right when:

The problem is generic. Customer support chat, generic document Q&A, prompt-based content generation. There are mature products (Intercom Fin, Glean, Copy.ai). They've been built for the average use case and they fit yours.

The data residency is non-sensitive. The SaaS product runs on the vendor's infrastructure. Your data flows through their pipeline. If that's acceptable — most non-regulated use cases — buying is the fastest path.

The integration surface is small. A chatbot that ingests your knowledge base via API and surfaces a widget on your support page. Light integration. Bought solutions handle it cleanly.

You don't need differentiation. If the AI is supporting infrastructure (e.g., internal employee Q&A) rather than a competitive differentiator (e.g., the core product), buying is right. Don't custom-build commodity infrastructure.

Cost is bounded. Per-user or per-call pricing models that you can ceiling. If usage might explode and bankrupt you, the math changes.

We turn down engagements where buying is clearly right. We tell the client: "Intercom Fin or Glean fits this; spend $50K/year there instead of $200K on a custom build."

When to build

Building in-house is right when:

You have a strong existing engineering team with ML or LLM experience. This is the load-bearing prerequisite. Without it, the build path takes 3× longer than projected and ends up technically debt-heavy. With it, the build can be excellent.

The use case is core to the product. A search company building search. A legal-tech company building contract analysis. A code-completion company building autocomplete. The AI isn't supporting infrastructure; it's the product. Differentiation matters; control matters.

Time isn't critical. Building well takes 6-18 months. If a competitive product is launching in 90 days, building loses by default.

The team can sustain the system after launch. AI systems require ongoing care — model updates, eval set maintenance, prompt iteration, cost monitoring. Without dedicated headcount, in-house builds rot.

Compliance posture requires it. Some regulated industries can't accept a vendor's terms of service or data handling. Build internally; control the entire stack.

We see fewer client-side build paths than ideologues might expect. Most companies don't have the AI/ML headcount to sustain a build. Those that do (Google, Stripe, large banks) do build, and they don't generally call us. The middle of the market either buys or hires a firm.

When to hire

Hiring a firm is right when:

The use case is specific but not generic. Generic = off-the-shelf SaaS fits. Specific = needs custom work tailored to your data and workflow. A typical fit: "we need a custom-fine-tuned model for our legal document review with specific output formats." No SaaS covers this exactly. You don't want to spin up an in-house team for one project.

You need it shipped in 8-16 weeks. Firms come pre-loaded with infrastructure, methodologies, and lessons learned. A good firm ships in 1/3 the time of a from-scratch internal build.

Compliance posture requires customization. On-prem deployment, custom retention rules, audit trails matched to your industry's expectations. SaaS doesn't deliver this; in-house build does but takes 18 months.

You want to keep the asset. Good consulting engagements end with the client owning the model, the eval harness, and the deployment infrastructure. The firm provides expertise during the engagement and walks away. The client carries it forward without dependency. This is our standard engagement shape.

You need expertise more than warm bodies. An internal team can write code; what they may not have is the judgment to pick the right model, the right training data, the right architecture. A firm brings that judgment.

The trap to avoid: hiring a firm for the "buy" or "build" scenarios. Hiring is the right tool for the middle, not the ends.

What changes the answer

Some signals that should swing the decision:

Data sensitivity high. Rules out most SaaS. Pushes toward build or hire.

Headcount available with relevant experience. Pushes toward build.

Time pressure. Pushes toward buy (or hire if buy doesn't fit).

Differentiation required. Pushes away from buy. Build if you can sustain it; hire if you can't.

Compliance requirements. Pushes toward on-prem hire or in-house build.

Scale unbounded. Pushes away from per-call SaaS pricing toward on-prem.

One-off vs. ongoing. One-off problems with clear edges: hire to ship and walk away. Continuous systems with evolving requirements: build.

A decision matrix

Use case shape	Buy	Build	Hire
Generic + non-sensitive + small surface	✅
Generic + non-sensitive + need it tomorrow	✅
Generic + sensitive		✅	✅
Specific + we have engineers		✅	✅
Specific + we don't have engineers			✅
Specific + need it in 90 days			✅
Core to our product		✅	✅
Supporting infrastructure	✅
Compliance-driven		✅	✅

What goes wrong with each

Buy gone wrong: vendor lock-in, data leakage, scaling cost surprise, mismatch with your specific data shape that you discover after deploying. Mitigation: read contracts carefully, plan for migration paths, prove value at small scale before committing.

Build gone wrong: scope creep, team turnover mid-project, "we'll add ML later" turning into never, model serving infrastructure becoming a 0.5-FTE drag forever. Mitigation: time-box the build, ship a v0 in 8 weeks, sustain only if you have stable headcount.

Hire gone wrong: the firm delivers something the client can't operate, the engagement ends and the model rots, the firm's recommendations don't match how the client actually operates. Mitigation: choose firms that hand over operability, not just artifacts. Make sure the engagement includes documentation and training. Validate that internal teams can run the system at engagement end.

Hybrid paths

The cleanest engagements often combine paths:

Hire to build, then operate in-house. The firm builds the v1, hands it over with documentation and training. The client's existing team takes operational ownership. The firm stays on retainer for major changes.

Buy for the common 80%, hire for the custom 20%. Use Glean for general document Q&A. Hire to build the specialized legal-clause review pipeline. The two systems coexist.

Build the core, buy the periphery. Internal team builds the core differentiator. SaaS handles support, ops, monitoring, eval tooling that isn't differentiating.

These hybrids aren't compromises; they're often the optimal answer. Pure buy / pure build / pure hire is rarer than the marketing material suggests.

What we ask on a first call

The triage we run, in order:

1. Is this generic or specific? (If generic, look at SaaS first.)
2. What's the data sensitivity? (If high, SaaS often ruled out.)
3. Does your team have AI engineering depth? (If no, build is rarely the right answer.)
4. What's the timeline? (Compresses options aggressively.)
5. Is this core to the product or supporting? (Influences whether differentiation matters.)
6. What's the compliance shape? (Often a hard constraint.)

The honest answer is often "buy" or "build with internal team." We say so and decline the engagement. The engagements we take are the ones where hire-a-firm is genuinely the best path. Those engagements end well because the foundation is right.