The build vs buy AI question sounds binary, but it almost never is for a mid-market operator. Most vendor pages frame it as "subscribe to our SaaS" or "hire a team and build from scratch," and both sides quietly bury the parts that hurt: renewal creep, data lock-in, model drift, staffing gaps, roadmap misalignment. There is a third path that fits most mid-market situations better than either extreme, and it is the one nobody writing about build vs buy wants to talk about because they do not sell it.
Key takeaways
- The real decision is not build vs buy, it is whether the AI reads and writes inside the software you already run or lives in a separate product you rent.
- A fixed-fee AI Capability Audit costs $7,500 and produces a written scope before any build is agreed.
- Every write to a live record in a Throughline-built system goes through a person on the client's team for approval.
- Inside Kelsan, a multi-state distributor running Epicor P21, our rebate-and-margin tool has recovered over $100,000 in margin that would otherwise have been lost.
- Buying makes more sense than building when the problem is generic, the data lives in the vendor's product, and switching cost is low.
The framing most articles get wrong
Buy-side content pretends the vendor tool is the finish line. Build-side content pretends a full custom platform is the only serious answer. Both dodge the same fact: the work that actually moves margin for a mid-market business is usually stuck inside documents and records the business already has, sitting in an ERP or an accounting system nobody wants to rip out.
The right question is not "should we build or buy?" It is: "where does the AI need to read from, and where does it need to write to, for this chore to be done?" Answer that, and the build vs buy path picks itself.
When buying is the right call
Buy when the capability is generic, the data can safely live in the vendor's cloud, and you can leave without a scar. Meeting transcription, standalone chat interfaces, generic writing assistants, code completion. These are commodity capabilities. Somebody has already built the better version. Renting it is cheaper than building it and probably always will be.
Buy also makes sense when the workflow is fully contained in one SaaS product you already pay for and that vendor is shipping AI features into their own tool. If your CRM ships a decent summarizer, use it.
The honest tradeoffs on the buy side: you rent forever, prices go up, your data trains their model unless you paid for the tier that says otherwise, and the roadmap belongs to them. Pricing pages like aisera pricing rarely show the number you will actually pay after seat expansion, custom connectors, and premium support get added. Ask for the two-year cost, not the sticker.
When building from scratch is the right call
Build from scratch when the capability is core to how you compete, no vendor sells it, and you have the engineering bench to maintain it for years. Very few mid-market companies meet all three. If you do, you already know it, and you are probably reading this to confirm a decision you have made.
The honest tradeoffs on the build side: maintenance drag is real, model providers change their pricing and behavior without asking, and the team that built the thing has to still be there in year two. Generic guides on build vs buy software development costs benefits risks tend to underweight the year-two staffing problem. That is where most in-house builds quietly die.
If you do need something bespoke, that is what generative AI development is for, and it should be scoped in writing before a line of code gets written.
The third path: build INTO the software you already run
Most of the useful work sits between the two extremes. You do not need a new SaaS subscription. You do not need a from-scratch platform. You need a small, specific system that reads the documents and records already flowing through your business, does the tedious matching work, and hands entries to a person to approve before anything posts.
That is what we build. The AI reads. A person approves. The ERP or the accounting system stays where it is.
This is where the buy-vs-build framing collapses. You are not buying a product. You are not building a platform. You are adding a capability into the software your team already opens every morning. It looks less impressive in a demo and works better in a Tuesday.
A concrete proof, not a hypothetical
Inside Kelsan, a multi-state distributor in our own group running Epicor P21, we built a rebate-and-margin recovery system. It reads supplier rebate documents, matches them against invoices in P21, and surfaces entries a person approves before they post. It has recovered over $100,000 in margin that would otherwise have been lost.
That system is not a SaaS product we resell. It is not a custom platform we spun up in isolation. It reads from documents Kelsan was already receiving and writes into the ERP Kelsan was already running. A human on the team approves every entry that touches a record. You can read more about the rebate-and-margin tool we built inside Kelsan if the mechanics matter to your decision.
We built it inside our own group first because that is how we prefer to work: prove the pattern in a business we operate, then offer it to yours. The same pattern applies to AI for distributors more broadly, wherever documents, invoices, and an ERP are involved.
A three-step decision framework
Use this before you write an RFP or sign a subscription.
- Name the chore, not the technology. Write one sentence: "A person on our team spends N hours per week doing X, and the answer is already in these documents or these records." If you cannot write that sentence, you are not ready to build or buy anything.
- Locate the data. If the answer lives inside your ERP, your accounting system, or documents that arrive in email, the third path (build into the systems you already run) is almost always cheaper over two years than either extreme. If the data lives in a vendor's product, buy their AI feature. If the data does not exist yet and never will without a new system, build.
- Decide who approves the write. Any AI that changes a record needs a named human who approves the change. If the vendor cannot show you the approval step, that is a red flag. If your internal build plan skips it, that is a bigger one.
Most people writing a build vs buy rfp ai software document forget step three entirely. Put it in section one.
What buy vs build looks like differently at mid-market
Enterprise decisions and mid-market decisions are not the same. Enterprises can afford a two-year platform build and a dedicated internal AI team. Mid-market cannot, and should not pretend otherwise. The mid-market advantage is speed: you can point a small system at a specific chore, ship it in weeks not quarters, keep a human in the loop, and measure the result in the ledger.
That is why the buy vs build conversation at mid-market usually ends with "neither, exactly." It ends with ERP automation or intelligent document automation wired into the software your team is already logged into, not a new tab and not a new platform.
Your next step
If you are weighing this decision now, the fastest way to get an honest answer is to put the specific chore in front of someone who has built the third path in a live business. Book a call with Throughline, or start with a fixed-fee AI Capability Audit ($7,500). The call is free. Call 865-417-3554.
About the author
Throughline is a small team of builders inside Keller Group. We build AI systems into our own operating companies first, then into yours.