Build vs Buy vs Configure: A Decision Framework for Growing Companies

Your operations team has outgrown the spreadsheet. Someone suggests Salesforce. Someone else says “just build it.” A third voice pipes up: “Can’t we just configure what we already have?” Three weeks later you are still in the same meeting, and nothing has shipped.

This is the build vs buy vs configure trap — and it costs companies far more than the software itself. Gartner research found that 68% of fast-growing businesses regret a software purchase, and 31% have already ripped out and replaced a tool because the total cost spiralled past expectations. Getting the decision right the first time matters.

The Three Options, Plainly Stated

Buy off-the-shelf (SaaS). You subscribe to a product — QuickBooks, Shopify, HubSpot, Xero — and adapt your process to fit it. Fast to deploy, low initial outlay, vendor handles infrastructure and compliance updates.

Configure. You already own or license a platform and extend it using its native tools: Shopify Flow automations, Salesforce no-code flows, Zapier connecting your existing stack. No new contract needed. Often underutilised.

Build (custom software). You commission software designed specifically for your workflow — either through an in-house engineering team or a development partner. Higher upfront investment; you own the result.

Why “Just Buy It” Is Not the Safe Default

The sticker price on a SaaS contract is not the cost. Analysis of enterprise SaaS total cost of ownership consistently shows the true TCO running 2.5x to 4x the advertised subscription price once you account for implementation, data migration, training, and integrations. For a 500-seat deployment, ServiceNow’s AI-tier upgrade mandate alone added $180,000 to annual contracts.

Worse, vendors raise prices. Salesforce increased enterprise contracts by 19% in 2025. SAP migration pricing added an average of 42% to legacy equivalents. Annual SaaS price escalations are currently averaging 25%–35% across the market.

And then there is the shelfware problem. According to Zylo’s 2025 SaaS Management Index, 52.7% of SaaS licenses sit unused, and the average company wastes roughly $21 million per year on software nobody opens. Most enterprise SaaS products ship far more features than any single customer ever uses — you pay for the whole catalogue whether you need it or not.

None of this means you should never buy. It means you should price it honestly.

The Configure Option: Chronically Ignored

Before writing a procurement order or a software brief, audit what you already have. Most companies running Shopify, Salesforce, or a modern ERP are using a fraction of its configuration capability.

Shopify Flow is free on every plan and handles most common e-commerce automations. Salesforce’s native no-code tools can cover a significant share of CRM workflow requirements without a single line of code. Zapier connects 8,000+ apps — and most legitimate SaaS products already integrate with it.

Configure first. The time investment is measured in days or weeks, not months. If configuration covers 80% of the requirement without becoming a maintenance nightmare of nested workarounds, you may not need to go further.

The signal to stop configuring: when your “workflow” requires three Zapier zaps chained together, a custom field that fights the data model, and a manual step that someone has to remember every Thursday. At that point you have built fragile software — just slowly, and with no ownership.

A Practical Decision Framework

Work through these three questions in order.

1. Is this a commodity function or a competitive differentiator?

Order management, payroll, accounting, email marketing: these are commodity functions. Someone has already built excellent software for them. Buying is almost always right.

Order routing logic that reflects the specific rules of your 14-warehouse fulfilment network, a pricing engine that accounts for your margin structure and contractual commitments, a customer portal that integrates with three legacy systems from your 2019 acquisition — these are differentiators. Configuring a generic tool to mimic your logic produces a brittle approximation. Building gives you something that actually fits.

2. What does the five-year total cost actually look like?

For most mid-market applications, a well-scoped custom build runs $150,000–$400,000 in year one. Annual maintenance typically runs 15%–20% of the initial build cost. That sounds significant until you model it against a SaaS contract that starts at $80,000/year and compounds at 30% annually.

For a 200-seat deployment, break-even on custom software arrives at approximately 14 months. For a smaller 50-user team, that extends to around 28 months. Beyond that horizon, custom software is almost always cheaper — and it does not charge you again when you add users.

3. Do you understand the problem well enough to specify it?

This is where most custom builds go wrong. Teams that cannot write a clear problem statement end up specifying the wrong thing, then blaming the developer when reality arrives.

If the scope is unclear, a discovery engagement — typically $50,000–$100,000 with an experienced development partner — is the right first step. It produces a specification, architecture decision, and realistic cost estimate. It is cheap insurance against a six-figure mistake.

The In-House Engineering Question

One option that often enters the conversation is hiring engineers directly. The arithmetic is harder than it looks. A senior software engineer’s median US salary is $130,160, and fully loaded (benefits, employer taxes, equipment, management overhead) that reaches roughly $200,000. A minimal in-house team capable of owning a meaningful system runs $1 million–$1.5 million per year. Tech sector turnover averages 13.2%, meaning you are constantly rehiring and onboarding.

In-house engineering makes sense when software is your core product, or when the systems you are building require continuous iteration at a pace no external partner could match. For most SMBs and mid-market operators, a partner-build model — commissioning and owning custom software through an external engineering firm — delivers the same outcome at a fraction of the overhead.

Making the Call

Start with configure. If configuration leaves meaningful gaps in the core process, model the five-year TCO for a SaaS buy versus a custom build. If the process is a competitive differentiator and the numbers are close over five years, build — and own it.

The decision that tends to hurt companies most is the default buy: signing a large SaaS contract without modelling TCO, without auditing existing tools, and without asking whether the process is truly generic enough that someone else’s product will fit.

---

If your team is facing this decision and wants a second pair of eyes on the numbers, we are happy to have a free, no-charge conversation to work through the framework with you. No sales pitch — just a structured way to think about a choice that will affect your operations for years.

---

Sources: Feature23 — Build vs Buy Software: A Practical Decision Framework (2026); APIPilot — Custom Software vs. SaaS: A 10-Year Long-Term Cost & ROI Analysis (2026). Figures current as of mid-2026; verify against primary sources before acting.