AI build vs buy: a decision framework for mid-market operators

Score your workflow against the six inputs below, honestly. The goal is not a precise number but a direction: most decisions become obvious once the variables are named. Where two inputs pull in opposite directions, the tie-breaker is almost always specificity — how unique the workflow is to how you compete.

Treat the output as the start of a scoping conversation, not a verdict. A 'build' signal still needs a Diagnostic to confirm the bottleneck is real and the scope is bounded.

1) Annual cost of the workflow — the fully loaded cost of doing it today, including the people. 2) Monthly volume — how often it runs. 3) Specificity — how particular it is to your business versus a generic task any company has. 4) Data sensitivity — whether the data can leave your environment. 5) Existing tooling — whether a SaaS product already covers most of it. 6) Time horizon — how long you will rely on this workflow.

High cost, high volume, high specificity, and high data sensitivity push toward build. Low specificity and a strong existing SaaS option push toward buy. A long time horizon raises the return on a build; a short one favours buying.

Buy when the workflow is generic, well-served by mature SaaS, and not a source of competitive advantage — you should not build commodity infrastructure. Build when the workflow is specific to how you compete, expensive, high-volume, or constrained by data that cannot leave your environment, and you expect to rely on it for years.

Choose hybrid when the core is generic but the last mile is yours: buy the commodity layer, build the thin differentiating layer on top. Most mid-market AI wins are hybrids — the value is in the 20% that is specific to your operation.

A 'buy' result means your next step is vendor selection, not an engagement with PRIONATION. We will tell you so. A 'build' or 'hybrid' result means the next step is a two-week Diagnostic to map the bottleneck, confirm the scope, and price a fixed Build.

Either way, the framework has done its job if it stopped you from building something you should have bought, or buying something you should have built.

The inputs are not a checklist to total up; they interact, and the interaction is where most decisions actually turn. Cost and volume compound — a workflow that is expensive per run and runs constantly justifies a build that either alone would not. Specificity and data sensitivity reinforce each other in the same direction: a workflow that is unique to how you operate is usually also one whose data you would rather not hand to a third party. When several inputs point the same way, the answer is rarely in doubt, and you do not need this framework to see it.

The hard cases are the conflicts. A high-cost, high-volume workflow that is nonetheless generic — bulk document classification, say — tempts operators toward a build when a mature SaaS product would serve it for a fraction of the capital. Here volume is a red herring; specificity is the variable that should win. The reverse conflict is a low-volume but highly specific workflow at the centre of how you compete: low volume argues against the investment, but if the workflow is your edge, building it is defensible even at modest scale. The honest rule is that specificity and competitive relevance break ties; cost and volume size the prize once the direction is already set.

Time horizon is the multiplier sitting underneath all of this. A long horizon raises the return on every input that favours building, because a build is a fixed cost amortised over years while a SaaS licence is a recurring cost that never stops. The same workflow can read as 'buy' on a two-year horizon and 'build' on a five-year one, with nothing else changed. Before scoring anything, decide honestly how long you will rely on the workflow — getting that one input wrong distorts every other reading.

Consider three workflows to see the logic in motion. First, customer-support triage that routes tickets to the right queue: generic, well-served by mature tools, not a source of advantage. Every input points to buy, and building it would be spending capital to reproduce a commodity. Second, a pricing or quoting engine encoding rules no competitor shares, running on data you cannot expose, that you will depend on for years: specificity, data sensitivity, and horizon all align on build, and the cost of getting it wrong with a generic tool is structural, not just operational. These are the clean cases the framework names quickly.

The instructive case is the third, where the simple rule misleads. Imagine a workflow that looks generic on the surface — document summarisation — but where the value lives entirely in how your domain language, your formatting conventions, and your downstream systems shape the output. Score it naively and 'low specificity' pushes you to buy; a SaaS summariser then handles 80% of the task and fails on the 20% that actually mattered, because that 20% was the point. This is the classic hybrid trap. The fix is to score specificity on the part of the workflow that creates value, not on the workflow's generic-sounding label. Most mid-market builds that should have been hybrids were misread exactly here.

A second misleading pattern is the high-data-sensitivity workflow that operators reflexively mark as 'build'. Sensitivity does push toward build, but the honest caveat is that some SaaS vendors now offer compliant, in-region, single-tenant deployments that keep data within an acceptable boundary. If a mature product can meet your residency and access constraints, sensitivity alone is not decisive — it becomes a vendor-selection criterion rather than a build trigger. Treat data sensitivity as a hard filter on which buy options are admissible, and only as a build signal once no compliant buy option survives the filter.

The first misuse is scoring aspirationally rather than honestly. Operators mark specificity as 'high' because they want the workflow to be a differentiator, not because it is one. The discipline the framework demands is the same discipline a Diagnostic demands: describe the workflow as it actually runs today, with its real cost and its real uniqueness, not as the strategic narrative you would prefer. A workflow you wish were proprietary is still a commodity if a competitor could buy the same capability tomorrow. Aspirational scoring is how companies talk themselves into builds that the market has already solved.

The second misuse is using the framework to decide whether to build at all, rather than what to build first. The output is a direction for a single named workflow — not a verdict on your AI strategy. Operators who run the framework once, get a 'build' signal, and then commission a sprawling platform have skipped the step the framework exists to enforce: bounding the decision to one workflow whose cost, volume, and specificity you can actually state. If you cannot name the single workflow you are scoring, the framework has nothing to work on, and the right next move is a Diagnostic to find the bottleneck — not a build.

The third misuse is treating the result as permanent. A 'buy' decision made when no specific edge existed is correct on the day it is made and may stop being correct as the workflow becomes central to how you compete. The framework is a snapshot, not a standing policy. The honest limit is that it tells you the right call given today's cost, volume, specificity, and horizon — and says nothing about when those inputs will shift enough to change the answer, which is the subject of the section that follows.

A build-vs-buy result has a shelf life, because the inputs underneath it move. Volume grows: a workflow that ran a few hundred times a month when you bought a per-seat or per-call SaaS licence can, at scale, cost more in licence fees than a build would have cost outright — the classic moment a 'buy' quietly becomes a 'build'. Watch the recurring spend against what an owned system would have cost amortised over its remaining life; when the lines cross, the original decision is no longer the right one, regardless of how sound it was when made.

Specificity also drifts, usually in one direction. A workflow you bought as a commodity tends to accrete your own rules, exceptions, and integrations until it is no longer generic in any meaningful sense — you have effectively rebuilt a bespoke system inside someone else's product, paying rent on a layer that has become uniquely yours. This is the signal to revisit the hybrid option: keep buying the commodity core if one still exists, but bring the differentiating layer in-house where you control it. The trigger is not a calendar date; it is the moment your SaaS configuration starts to look like proprietary logic.

External change moves the answer too, and it moves in both directions. A capability that justified a build last year can become a commodity the moment a mature vendor ships it natively, turning a sensible build into maintenance you no longer need to carry. The reverse also happens: a vendor sunsets a product, raises prices, or fails your tightening compliance requirements, and a settled 'buy' reopens. The practical discipline is to re-run this framework on your significant AI workflows roughly annually, and immediately on any step-change in volume, in how the workflow differentiates you, or in the vendor landscape. The decision is cheap to revisit and expensive to leave stale.