AI: Build, Buy, or Wait? A Mid-Market Decision Guide

Every week another AI tool lands in your inbox, and every week someone on your team asks whether you should be using it. There's real pressure behind the question — a board that wants to hear you're "doing something with AI," a competitor who just announced a feature, a sense that the ground is moving and you don't want to be the last one standing still. So the instinct is to act: buy the tool, or greenlight a build, or spin up a pilot to look busy. The honest answer for most of what crosses your desk is that you don't need to build anything, and half of it you shouldn't even buy yet. The hard part isn't finding AI to spend money on — it's telling three things apart: the commodity you should buy and forget, the workflow that's specific enough to you that it's worth building, and the shiny capability that isn't real enough yet to touch. Get those confused and you either build something you could have bought for a seat fee, buy something that can't reach your actual systems, or pour a quarter into a pilot that was never going to ship. This is the framework we walk clients through before a single line of code gets written — including the parts where the right answer is "don't."

The three real options — buy, build, or wait

The decision is usually framed as build versus buy, as if those were the only two doors. There's a third one that saves more money than either: wait. A capability that demos well today but can't tell you what it costs to run at your volume isn't a build decision or a buy decision — it's a not-yet decision, and treating it as one keeps you out of the most expensive trap of all, which is being the company that finds out in production. So three options, not two. Each one is right in a specific situation, and the whole skill is matching the situation to the door. Buy when the problem is common enough that someone already sells a good answer. Build when the workflow depends on how your business actually runs — your data, your rules, your systems. Wait when the only proof a thing works is a video and a promise. Most wasted AI budget comes from picking the wrong door for the situation in front of you, not from the tools themselves being bad.

Buy when the problem is everyone's problem

If thousands of companies have the exact same problem — transcribing calls, drafting first-pass marketing copy, summarizing long documents, cleaning up meeting notes — then someone has already built a good tool for it, and dozens of someones are competing to make it better. Building your own version means spending months of senior engineering time to land roughly where a mature product already sits, minus the years of edge cases that product has already handled. That's not ambition, it's reinvention. Buy it, wire it into your process, and put your attention somewhere that actually differentiates you. The test for "buy" is whether your version of the problem is meaningfully different from everyone else's. Transcribing a call is transcribing a call — your audio isn't special. Drafting a product description follows the same shape whether you sell shoes or software. When the problem is generic, the tool being generic is a feature: it's been hardened by every other customer who hit a bug before you did. The moment you find yourself asking a vendor to build something just for you, that's the signal you may have wandered out of "buy" territory — but until then, paying a seat fee to skip the whole build is the cheapest good decision on this list.

Build when the workflow is actually your business

Build when the work is specific to how your business runs — your data, your approval rules, the systems only you have wired together the way you've wired them. A tool that reads your supplier invoices, applies your two-signature approval policy, and posts to your particular ERP setup doesn't exist off the shelf, because nobody else has your exact combination of formats, rules, and systems. This is where a custom build earns its cost: it removes work that no generic product can touch, because the work only exists in the shape your business gave it. That's the whole logic behind the shipped work we point clients to. SmallERP reads receipts, handles VAT, and runs payroll for small UAE businesses — not because "receipt reader" is novel, but because doing it against real UAE tax rules, in the messy formats those receipts actually arrive in, is specific enough that no generic tool covers it. The build is justified by the specificity, not by the AI being clever.

The trap inside "build": scope creep dressed as ambition

The failure mode on the build side isn't building the wrong thing — it's building too much of the right thing. A workflow that genuinely warrants a custom build almost always sits next to five that don't, and the temptation is to sweep them all into one project because you're building anyway. Resist it. The narrow build ships, gets used, and earns the right to grow; the everything build stalls in scope review for six months and teaches your team that AI projects don't finish. Pick the one workflow that's unmistakably yours, build that, and let the rest wait their turn — or turn out to be buys after all.

Wait when the capability isn't real yet

Some capabilities demo beautifully and quietly fall apart in production. The demo runs on a clean, hand-picked example; your Tuesday runs on the messy real thing, at volume, with the weird edge cases nobody put in the video. If the only proof a capability works is a viral clip, and nobody — not the vendor, not the internet — can tell you what it costs to run at your volume or how often it gets things wrong, that's not a build-or-buy question. That's a wait. Waiting feels like losing when everyone around you is announcing. It isn't. Waiting six months on an immature capability is far cheaper than being the company that wired it into a real workflow, discovered the failure rate the hard way, and spent the next quarter cleaning up records it corrupted. The capability that's genuinely not ready today is often perfectly ready two model releases from now — at which point it's a calm buy or a well-scoped build instead of a science experiment running on your live data. The cost of waiting is visible and small. The cost of being early on the wrong thing is invisible right up until accounting finds it.

The decision matrix — which door for which signal

The three rules collapse into a single table you can hold against almost any AI idea that lands on your desk. Read the signal on the left — the honest description of the situation you're actually in — and the verdict follows. Most decisions aren't close once you name the signal plainly; the mistakes happen when a build gets justified by enthusiasm, or a buy gets forced onto a workflow it can't reach.

A worked example: buy vs build for one real workflow

Abstract rules are easy to nod along to and hard to act on, so here's a concrete one. The numbers below are illustrative — made up to show the shape of the decision, not a client result, and your real figures will differ. Say your finance team processes about 200 supplier invoices a week. Each one takes roughly 6 minutes to check by hand: open it, match the line items to the purchase order, confirm the totals, file it or flag it. That's around 20 hours a week of steady, repetitive work — the kind of workflow where AI genuinely earns its place. The question isn't whether to use AI here. It's which door: buy a generic invoice-reading tool, or build one against your actual approval rules and ERP. The honest comparison isn't tool-A-versus-tool-B on features. It's a trade across three axes — what it costs, how long until it's working, and who owns and controls the result when the dust settles.

Notice what the table does and doesn't settle. It does not tell you "build" — for a plainer invoice flow with no unusual rules and a tool that already connects to your ERP, buying is clearly the smarter call, and no honest advisor would push a build on you. What tips this particular example toward build is the two-signature policy and the ERP integration: the moment a generic tool can't express your rule or reach your system, the seat fee buys you 70% of a solution and leaves the specific, valuable 30% undone. That's the line. Below it, buy. Above it, the specificity is exactly what justifies owning the build.

Where an off-the-shelf tool actually lands

The reason "buy the tool" so often disappoints isn't that the tool is bad — it's that a generic product is built for the average customer, and the value in your workflow lives in the parts where you're not average. A useful way to picture it: a bought tool typically covers the routine core of a workflow cleanly, gets shakier where your specific rules kick in, and simply stops at the edge of systems it has no connector for. The split below is illustrative — drawn from the pattern we see, not a measured statistic — but the shape is the real lesson.

If your workflow lives entirely in that first band — the routine core — then buying is the obvious, cheap, correct answer, and you should stop reading and go buy it. The decision gets interesting only when the value you're chasing sits in the amber: the rule the tool can't express, the system it can't reach. That's the 30% a custom build exists to carry, and it's also exactly the part a demo skips, because demos live in the clean 70%. When you're weighing a build, the honest question is how much of your real value is in that amber band — because that, not the model, is what you're actually paying to own.

Buy or build, the boring middle is still yours

There's a cost that doesn't show up on either side of the build-versus-buy ledger, and it's the one that decides whether an AI decision survives the year. Whatever you pick, something still has to check the AI's answers before they hit real systems, notice when a model update quietly changes its behavior, keep a record of what it did, and pause on the risky actions until a person says yes. We call this the boring middle — the unglamorous plumbing that never shows up in a demo and is the single biggest thing separating an AI setup that's still running next year from one that got switched off in month two. Buying doesn't exempt you from it; it just moves it. A vendor handles the checks inside their tool, but the moment their output crosses into your systems, the responsibility for catching a bad value is yours again. Building doesn't automatically include it either — a cheap build that skips the middle isn't 80% done, it's the easy 20%, and the hard, valuable 80% is precisely the part that keeps it trustworthy. This is the work that makes our operate-and-handoff engagements look the way they do: the checks, tests, monitoring, and human-in-the-loop approvals aren't a phase two, they're most of the actual job.

When a tool or a build reaches your systems, plan for the middle

This is also why the "buy a tool but it can't reach our systems" case so reliably becomes a small build rather than a shrug. You buy the capability — the generic thing the vendor does well — and then someone has to build the bridge to your ERP, your inbox, your database, with the checks on that bridge that stop a wrong number from flowing straight through. That bridge is a real build with a real boring middle, even though you bought the headline capability. Pricing a "buy" without pricing that integration is how a cheap-looking tool turns into a surprise project. It's the same discipline behind our work on Tethra, where several agents coordinate across a business's real tools and stop to ask a human before doing anything risky — so nothing costly happens unsupervised and the team that owns it can see exactly what it did.

Frequently asked questions

The bottom line

Buy the commodity and put your attention elsewhere. Build the thing that's actually your business — the workflow no generic tool can reach because it only exists in the shape you gave it. Wait on what isn't real yet, and don't mistake the waiting for losing. And when a workflow is too rare or too human to justify any of the three, leave it alone with a clear conscience. Almost all wasted AI budget comes from getting these confused: building a commodity, buying something that can't touch your real work, or rushing an immature capability onto live data to look decisive. Name the situation plainly and the door is usually obvious — which is exactly the conversation we'd rather have with you before anything gets built than after.