The honest answer, up front.
Buy more than you build. That is the answer most consulting houses will not give you, because they sell builds. For a $8M-$50M company, the large majority of the workflows you would point AI at are commodity workflows, and for commodity workflows a product almost always beats a commission on cost, speed, and risk. The custom build earns its place on exactly one kind of workflow: the one that is both your real bottleneck and specific to how your company operates. Spend custom money there, and buy everything else.
The fear in the room is usually backwards. Operators worry about over-building, about commissioning something expensive and bespoke when a tool would have done. That happens, but the more common and more expensive mistake is the opposite: buying a generic tool that almost fits the one workflow that was the whole reason you started looking. The tool handles the easy 90 percent that every company shares and misses the 10 percent that was actually your constraint. You pay a small subscription and the bottleneck is still there.
Commodity versus differentiated.
The entire decision turns on one distinction, so it is worth stating carefully. A commodity workflow looks roughly the same at every company in your size band. Drafting routine emails, transcribing calls, summarizing documents, answering common questions, taking meeting notes: these are not where your business is different from the firm down the street, and a product built for ten thousand companies will do them better than anything you would commission, because the vendor has amortized the work across all ten thousand.
A differentiated workflow is shaped by decisions, data, and sequencing that are specific to how you operate. It is usually the workflow that has resisted every tool you have tried, the one where someone on your team says "the software does not really work the way we do this." That resistance is the signal. A product never quite fit because the workflow was never standard, and the part that does not fit is, more often than not, the exact part that is your bottleneck.
Put plainly: you buy the commodity layer and you commission the differentiated one. The error is treating the whole company as differentiated (over-building) or treating the differentiated workflow as commodity (buying a tool that almost fits). Both are common. Both are avoidable with a short test.
The decision test, in three questions.
Before you decide build or buy on any workflow, answer three questions in order. They take a few minutes per workflow and they settle most cases without a vendor call.
One: is this workflow commodity or differentiated? Is it done roughly the same way at companies like yours, or is it shaped by something specific to how you run? If it is standard, lean buy and stop here. If it is specific to you, keep going.
Two: does an off-the-shelf tool reach 90 percent or more of it? Look at the real products, not the demo. Map your actual workflow against what the tool does. If a product covers nearly all of it and the rest is cosmetic, buy. If the tool covers the easy front of the workflow and stops exactly where your work gets specific, that gap is the tell.
Three: what does the last 10 percent cost you? This is the question that decides it. If the missing slice is a minor annoyance, buy the tool and absorb the gap. If the missing slice is the bottleneck, the part that consumes staff hours, produces the errors, or slows the response time you actually care about, then that 10 percent is not a rounding error. It is the reason to commission a build, because it is the only part worth building and it is the part no product will ever reach.
The tool that almost fits.
The most expensive purchase in mid-market AI is not the custom build that ran long. It is the SaaS tool that almost fits. Here is how it goes wrong. A product is sold on the 90 percent it does cleanly, demoed on sample data, and priced at a subscription that feels like a bargain next to a commission. You buy it. Then it meets your real workflow and the missing 10 percent turns out to be the specific part, the part that was your constraint in the first place.
From there, one of three things happens, and all three cost money the subscription line never shows. Your team bends its process to fit the tool, which means you have changed how you operate to suit software instead of the other way around. Or your team runs a manual workaround for the gap, which is the same labor you were trying to remove, now with a tool on top of it. Or people quietly stop using it, and you are paying for shelfware while the bottleneck sits exactly where it was. The cheap number was real. The solved problem was not.
This is the same failure pattern, viewed from the buy side, that shows up on the build side as the thin wrapper. We covered the build-side version in what a mid-market AI engagement costs: a generic chatbot pointed at a problem that needed a custom build works for the average company because it was built for the average company, and the mid-market operator with a non-standard workflow is, by definition, not the average company. Whether the not-quite-fit arrives as a tool you bought or a wrapper you commissioned, the diagnosis is the same: the workflow was differentiated and got treated as commodity.
When a custom build is actually right.
A custom build is the right call when three things are true at once. The workflow is differentiated, specific to how you operate rather than standard across your peers. An off-the-shelf tool cannot reach the part that matters, the 90 percent test fails on the slice that is your constraint. And the cost of that gap is real, measured in hours, errors, or lost speed that you can actually name. When all three hold, you are not choosing custom out of vanity; you are commissioning the only thing that can reach your bottleneck.
Note what this rules out. It rules out commissioning a build for a workflow a product already serves, which is paying bespoke prices for a commodity. It rules out "AI across the whole business" as a single custom engagement, which is over-building by definition, because most of the business is commodity workflows you should buy. The disciplined version is narrow: one differentiated workflow, scoped, built, and owned, with the commodity layer bought off the shelf around it. The reasons mid-market builds drift wide and stall are worth understanding before you commission anything, and we walk through them in why mid-market AI rollouts stall in month four.
There is also a sequencing point. You do not have to decide build-versus-buy in the abstract; you decide it per workflow, and the right order is usually to buy the commodity layer first, live with it, and let the genuinely differentiated bottleneck reveal itself by being the thing the tools still cannot touch. That is the workflow to commission, and it is the only one worth the custom spend.
How to run the decision without us.
You can do most of this yourself before any vendor is involved. List your workflows. Mark each one commodity or differentiated using the first test question. For the commodity ones, go buy the best product and move on; there is no engagement to scope and no reason to overthink it. For the differentiated ones, run the 90 percent test against the real tools, and for any that fail the test on the part that is your constraint, you have found a candidate for a custom build.
If you want the map made for you, the AI Maturity Index does exactly this sorting, separating the workflows you should buy from the one or two worth commissioning, and our diagnosis process exists to pressure-test that call before any money is spent. The framing to hold onto is simple. Build narrow, buy broad. Reserve the custom build for the workflow that is genuinely yours, and let a product handle everything that is not. Most of the time, that means buying, and that is the honest answer.