"Should we build our own AI or buy a SaaS tool?" is the wrong first question. Asked that way, leadership ends up making a single all-or-nothing bet on a category of decisions that should never be made at the category level.
Why the category-level bet fails
Companies that answer "build" at the category level end up with an eighteen-month internal platform project that reinvents commodity capabilities the market already sells for pennies. Companies that answer "buy" at the category level end up with a stack of AI-flavored subscriptions, none of which knows anything about their business, and a nagging sense that the competitive advantage everyone promised never materialized. Both outcomes come from the same mistake: treating "AI" as one decision instead of a dozen smaller ones that deserve individual answers.
The fix is to stop asking about AI in general and start sorting specific use cases into tiers. The tier determines the answer, and the answer is different per tier.
The framework we use
In every AI consulting engagement we run, we split the AI surface area into four tiers and decide separately on each:
1. Commodity capability. Speech-to-text, translation, generic OCR, basic summarization. These are commodities. Buy. Use the cheapest API that hits your accuracy threshold and move on. There is no defensible moat in building this yourself, and the market is improving these capabilities faster than any internal team could. The only engineering that belongs here is a thin abstraction layer so you can swap providers when the price or quality changes — which it will, roughly every six months.
2. Differentiated workflow on commodity capability. A clinical note summarizer for nurse practitioners. An invoice classifier that has to match your chart of accounts. A support agent trained on your knowledge base, with escalation rules that match how your team actually operates. Build the workflow, buy the model. The value is in the system around the model — the retrieval over your data, the validation rules, the integration into the tools your team already uses — not in the model itself. We have watched this pattern hold for years, well before the current AI wave: when we built the APEA platform for nurse practitioner education, the durable asset was never any single piece of technology. It was the workflow fit — four applications and an e-commerce layer shaped around how practitioners actually study, test, and buy. Tier-2 AI works the same way.
3. Proprietary data advantage. Predictions or generations that meaningfully improve when the system is grounded in your private data — years of quotes and outcomes, service history, clinical content, claims records. Build, with a serious data plan. This is where bespoke AI earns its keep, and where pilots usually die, because the data plan was an afterthought. A serious plan answers unglamorous questions: who owns the data contractually, is it in retrievable form or trapped in PDFs and legacy tables, how do corrections flow back in, and who is accountable for quality a year from now. If nobody can answer those, the use case is not tier-3 yet — it is a data project wearing an AI costume, and it should be budgeted as one.
4. Frontier research. Pushing the state of the art in a research-heavy way — novel model architectures, domains where no foundation model performs. Hire a specialized team or partner with a lab. Almost no operating business actually needs this, and the ones that do usually know it already. If a vendor is telling you that your invoice-routing problem requires frontier research, get a second opinion.
Running the sort takes a week, not a quarter
The exercise itself is fast. List every AI idea floating around the organization — the ones in the strategy deck and the ones living in a department head's wishlist. For each, ask two questions: would a competitor with the same tool get the same result (if yes, it is tier 1), and does the result get materially better with data only we have (if yes, it is tier 3). Everything between those poles is tier 2. In our experience the distribution is lopsided: most initiatives turn out to be tier-1 commodity work you should buy and stop discussing, a meaningful handful are tier-2 workflow plays that justify a real engagement, and only a small remainder are tier-3 data plays worth deep investment. Tier 4 almost never appears.
That lopsidedness is the point. The sort tells you where not to spend money, which is half of strategy. It also keeps you honest about the buy column: SaaS is the right answer for tier 1, but it stops being cheap at scale, and the seat-license math deserves the same scrutiny as the build estimates — we walked through that arithmetic in our post on the real cost of off-the-shelf SaaS.
Where "hire" actually fits
Hiring is not only the tier-4 answer. The more common version is smaller: most mid-sized companies do not need a standing AI team, they need senior engineers for the duration of a tier-2 or tier-3 build and a maintainable system left behind afterward. A full-time ML hire makes sense when the tier-3 backlog is deep enough to keep one busy for years. Short of that, a partner engagement with a defined start and end — discovery, prototype, production, then handoff — costs less and avoids the awkward question of what the AI hire does in month nine.
If the AI conversation in your organization keeps stalling because the answer keeps being "well, it depends," it usually does — on which tier the specific use case lives in. Sort that out and the rest of the strategy stops being a debate. And if you want a second set of eyes on the sort, that is exactly what the discovery phase of our AI development practice here in Lafayette exists to do: a few weeks of structured work that ends with a written roadmap, tier assignments, and honest recommendations — including the ones that say "buy this, do not hire us for it."