For twenty years, the default answer to “do we build this or buy it?” has been buy it. Building was expensive, slow, and distracting. The SaaS market had a product for everything.

That argument is breaking. Not for systems-of-record (CRM, accounting, identity), but for the long tail: workflow tools, niche platforms, the three-product assemblies cobbled together to do one job. There’s now a third option that didn’t exist eighteen months ago: a senior operator with AI-augmented delivery tooling, building the bespoke version in weeks at a cost that changes the maths.

This is a framework for thinking about that decision honestly. Sometimes buying is still right. The framework should tell you when.

What changed

The traditional calculation was simple. Buy gave you weeks to value, low risk, generic fit. Build gave you twelve months, an engineering team, exact fit. For most problems, buy won easily.

What changed is the build column. AI-augmented delivery (Claude for code, Gemini for infrastructure, equivalents across the toolchain) has compressed the time dimension by 3–4x for the kind of work mid-market organisations need. A platform that required a four-person team for twelve months can now be delivered by a senior operator in eight to ten weeks. Cost compresses with time.

That doesn’t kill buy. It moves the threshold.

Three signals build might be right

You’re assembling three or more SaaS products to do one job.

Tool A for orchestration, Tool B for visibility, Tool C for governance, glue code in between. The combined cost (subscriptions, integration, operational burden) often exceeds a focused build. The case strengthens if any integration is fragile or vendor-roadmap-dependent.

The off-the-shelf options are designed for someone slightly different.

SaaS is built for the median customer in its segment. If you’re at the edges (more regulated, specific workflow, off-curve scale) you’ll spend significant time adapting your process to fit the tool. That cost is invisible until you’re a year in, with parallel workflows built around the tool’s limitations.

The tool doesn’t exist.

The strongest signal. If the product you want to subscribe to genuinely doesn’t exist, if you’re piecing it together from adjacent tools, that’s a build candidate. Ten years ago this meant build it expensively or live without. Today, AI-augmented delivery puts build in reach.

Three signals buy is still right

Mature category, good products, typical buyer.

CRM, accounting, payroll, identity, observability. Vendors have invested billions in features you’d be reinventing. If your needs are typical for your size and sector, buy. Build is a distraction.

Regulatory or commodity work where audit trail matters more than fit.

Endpoint protection, vulnerability scanning, baseline SOC 2 controls. Building costs little. Defending a bespoke build to auditors and procurement costs a lot. Buy.

No leadership commitment.

The killer. Custom platforms succeed when leadership owns them. They fail when they’re delegated to whoever volunteered. If you can’t name the accountable owner six months from now (with authority and capacity to keep showing up) buy and move on.

The senior operator is what’s new

A decade ago, “build instead of buy” for a mid-market organisation meant “hire a four-person engineering team for a year.” Prohibitive for most problems, even good ones. Buy won by default.

A senior operator working AI-augmented can now credibly deliver platforms that previously required a team. AI doesn’t replace the judgement. Architecture, integration, security, compliance, operational handover all still need an experienced operator. But throughput per operator is 3–4x what it was, and cost follows.

The threshold has moved. Problems that sat firmly in the buy column because “we can’t afford to build” now have a credible build path.

How to run the decision

Inventory the candidates. List systems and workflows where the current state isn’t working: assembled tools, workarounds, gaps. Include things coming in twelve months, not just current pain.

Score against the six signals. Three or more build signals: evaluate a build. Three or more buy signals: stay off-the-shelf. Mixed: look harder.

For build candidates, run the numbers. Realistic delivery cost: senior operator time, integration, handover. Realistic alternative cost: subscriptions, integration burden, process adaptation. The numbers usually decide it.

Secure leadership commitment before anything starts. Name the accountable owner. Not the sponsor, not the budget holder. The person paying attention six months in.

Run a discovery sprint before the full build. One to two weeks producing an architecture, a phased plan, and a build-or-guide recommendation. If discovery surfaces “actually, buy this”, that’s a successful discovery. Two weeks beats six months.

The next two years

Buy-vs-build will be a more active conversation in mid-market technology than at any point in the last decade. Not because build wins by default (most decisions still go buy) but because build is genuinely on the table where it wasn’t before.

The organisations that benefit will develop a working framework for evaluating honestly, defaulting to neither side. The work is in the evaluation, not in the answer.

If this is a conversation your organisation is starting to have, the AI Opportunity Assessment engagement (six weeks producing a discovery document, an opportunity matrix and a working prototype of the highest-priority quick win) is built around exactly this evaluation.

Keith Biggin runs Biggin Insights, a senior technology leadership practice. Engagements take three shapes (Lead, Build and Guide) built around the same operator-grade credibility. About the practice · Services · Book a conversation.