Build vs Buy: When Off-the-Shelf Software Is Enough

The default answer is buy

Off-the-shelf software carries advantages no custom build can match on day one: it exists now, it is tested by thousands of other customers, someone else fixes its bugs and patches its security, and it improves without you paying for the improvements. For commodity functions — email, accounting, documents, calendars, payroll — these advantages are decisive and the decision is not close.

The question worth asking is never "could we build this?" — you nearly always could. It is "is this function commodity or distinctive?" If a thousand other businesses need exactly what you need, the market has already built it, amortised across all of you. Buy it.

What does market data say about the buy side?

Buying at scale has a measured waste problem. Zylo's SaaS Management Index — drawn from the large organisations it monitors — found the average company in its dataset running roughly 300 SaaS applications, leaving about a third of licences unused, and wasting $19.8 million a year on licences nobody logs into. Small businesses run smaller numbers, but the mechanism is identical: subscriptions accrete, seats outlive the people who used them, and nobody audits.

Prices are moving the wrong way too. Vertice's SaaS Inflation Index recorded software prices rising 11.4% year on year against average G7 consumer inflation of 2.7%, with 58% of vendors raising list prices in a single year. Gartner, meanwhile, forecast worldwide SaaS end-user spending reaching $299.1 billion in 2025, up from $250.8 billion the year before — the direction of the whole category is up.

None of this makes buying wrong. It makes unaudited buying expensive, and it means the "safe default" carries a compounding cost that deserves the same scrutiny a build quote gets. A one-off $2,000 build proposal triggers a meeting; a $59-a-seat subscription that will quietly cost ten times that over three years triggers a card payment. Pointing the same scepticism at both is most of the discipline this decision needs.

How does the three-year arithmetic work?

Subscriptions feel cheap because they are quoted monthly and per seat. Multiply them out. A $49-per-seat tool for 10 people is $5,880 a year — $17,640 over three years, before the near-universal annual price rises. Add the second tool you adopted because the first lacked a feature, and the hours someone spends each week bridging the two with exports and spreadsheets, and the true cost of "buying" is often multiples of the sticker price. We run the same model over a longer horizon in our custom software vs SaaS comparison.

Against that, a focused custom tool at $500–$2,500 fixed, hosted on your own cloud for a few dollars a month, is not the extravagant option — it is frequently the cheap one. The table shows the shape of the comparison for a 10-seat team; plug in your own numbers.

When is buying clearly right?

Buy when the function is commodity, when you need it immediately, when compliance and security certifications matter and the vendor already holds them, and when your requirements are still changing so fast that anything you build would be obsolete in six months. Buy especially when the honest driver of "build" is that someone finds the idea interesting — engineering curiosity is a wonderful thing and a terrible procurement criterion.

Buy also when the off-the-shelf product's opinionated workflow is better than yours. Tools like Stripe for payments or HubSpot for CRM encode years of learned best practice; a young company often benefits more from adopting those defaults than from encoding its current improvised process in custom code, and what a bespoke CRM costs to build only starts to matter once those defaults stop fitting.

When does building win?

Build when the workflow is genuinely distinctive — when the way you operate is part of why customers choose you, and every off-the-shelf tool forces you to flatten that difference. Build when per-seat pricing scales against you: the tool that was fine at 5 seats becomes a five-figure annual line at 40. Build when you need two systems to talk to each other and no integration exists. And build, obviously, when the software is the product you sell.

Build, finally, when the missing 10% is where the pain is. A team that lives inside a spreadsheet-and-email workaround for a feature its SaaS lacks is already paying for custom software — in hours and errors — without getting any.

How risky is the build side?

Building has its own documented failure statistics, and pretending otherwise would be salesmanship. McKinsey's research with Oxford across more than 5,400 IT projects found large projects running 45% over budget on average; the Standish Group's CHAOS research found only 16.2% of projects in its original study delivered on time and on budget. Custom software's bad reputation was earned honestly — by big, long, loosely scoped projects.

The same research contains the antidote: the Standish data puts small-project success around 90%. Risk tracks size, which is why the sensible way to build in this decade is small and fixed — one workflow, one tool, one integration at a time, each phase cheap enough that a failure is a bruise rather than a wound. A $1,725 internal tool that misses is annoying; a $250,000 platform that misses is a crisis.

What is the hybrid approach?

The build vs buy framing suggests a binary, but the most common right answer is both: buy the commodity core, build a thin custom layer around it. Keep Stripe for billing, HubSpot or a lightweight CRM for contacts, Slack for chat — and build the small connective tissue that is specific to you: the integration that syncs them, the dashboard that reads from all three, the automation that eliminates the weekly copy-paste ritual — n8n, Zapier or Make usually carries that layer.

These thin layers are exactly what AI-assisted development has made affordable. An integration or workflow automation runs $500–$1,800 in our bands; a custom dashboard on top of tools you already own, similar. You get the fit of custom software where fit matters and the economies of mass-market software everywhere else.

A worked example: one stack, audited

A 12-person services firm we can describe generically ran the pattern every audit finds: a project tracker at $15 a seat ($2,160 a year), a reporting add-on at $99 a month ($1,188 a year), and a five-hour weekly ritual of copying data between them and a spreadsheet — call it $6,500 a year of staff time at modest rates. Total: roughly $9,800 a year, about $29,500 over three years, for a workflow everyone privately worked around.

The hybrid rebuild: keep the tracker (the team likes it), cancel the reporting add-on, and build a small dashboard-plus-sync tool that reads the tracker's API — the kind of build that sits near our internal-tools median of $1,725 and dashboards median of $1,600. One-off cost under $2,000, hosting perhaps $10 a month, and the five-hour ritual gone. The three-year saving clears $20,000 without touching the tool that was actually working.

PINCLER's perspective: what focused builds cost

Published medians beat estimates, so here are the categories that most often replace or extend bought software, taken from PINCLER's published catalogue of 79 fixed-price builds — the full catalogue is in our project research. Every build sits inside $500–$2,500, and a $1,000 budget reaches 55 of the 79.

Who should build, and when should you not?

Build when the process is a genuine differentiator, when you are paying per seat for a fraction of a product's features, or when the tools you rent cannot be made to talk to each other without somebody copying data between them by hand. Those three situations are where a build repays itself, and they are narrower than most build advocates will admit.

Do not build if a mainstream tool covers the workflow with configuration alone — a bad configuration is far cheaper to fix than a bespoke replacement. Do not build if the process changes every quarter, because you would be paying to freeze a moving target. And do not build if nobody in the business will own the result: software without an owner rots faster than it depreciates, and the first symptom is usually a customer noticing before you do.

The clearest signal to buy is boredom. Payroll, accounting, email, calendars, storage, video calls — all standard, all better served by a vendor whose entire business is keeping them current and compliant. Spend the build budget on the part of your operation that nobody else does the same way.

• Build — differentiating workflows, per-seat pricing you are outgrowing, or integration gaps nothing off the shelf closes.
• Buy — commodity functions, regulated areas where a vendor absorbs the compliance work, anything you would resent maintaining.
• Do not build — a process still changing quarter to quarter, or a tool you have not configured properly yet.
• Wait — no internal owner for the result, and no measure agreed before the work starts.

What are the common mistakes on both sides?

The classic buy-side mistake is solving a workflow problem with another subscription. The team feels the pain of tools that do not talk to each other, so it buys a third tool that promises to unify them — and now three subscriptions and a new sync problem exist where two did. The audit habit prevents it: before any new licence, ask whether the gap is a missing product or a missing connection, because connections are build territory and cost less.

The classic build-side mistake is feature parity. A team decides to replace a $30-a-month tool and specifies everything that tool does, most of which nobody uses — turning a $1,500 focused build into a $20,000 fantasy that never ships. The discipline is to build the 20% of features carrying 100% of your actual usage, which is what keeps a replacement inside a fixed-price band and a two-week timeline.

A quieter third mistake spans both: deciding once and never revisiting. Seat counts change, vendors reprice, and a decision that was right at 5 people can be wrong at 25. The three-year sum is not a one-off ritual; rerun it when the renewal notice lands.

A five-question checklist before you decide

Run any build-vs-buy decision through five questions. Is this function commodity or distinctive to us? What is the honest three-year cost of buying, including workarounds? What is the fixed-price cost of building the focused version — not the everything version? Who maintains what we build? And can a hybrid — buy the core, build the layer — capture most of the value for a fraction of either extreme?

If you would like a second opinion with real numbers attached, that is what our free 30-minute call is for: describe the workflow, and you get a written fixed quote within a working day — or an honest recommendation to buy something off the shelf, which we give more often than you might expect. The workflow automation and third-party integration use cases show what the thin custom layer typically looks like.

Is the function commodity or distinctive?
│
├─ COMMODITY → BUY
│   (accounting, email, payroll, core CRM)
│
└─ DISTINCTIVE → is it the whole system,
    or the gap between bought tools?
    │
    ├─ THE GAP → HYBRID: buy the core,
    │   build the layer ($500–$1,800)
    │
    └─ THE SYSTEM → BUILD, in small
        fixed-price phases