Custom Software vs Off-the-Shelf: How to Choose

The custom software vs off-the-shelf decision comes down to one question: is the process you’re buying software for the same as everyone else’s, or is it the reason customers pick you? If it’s standard, buy. If it’s your edge, or if your team already spends more hours working around a tool than the tool costs, build. Most companies end up doing both, and the expensive mistake is drawing the line before anyone has written the process down.

That’s the short version, and plenty of articles stop there. This one goes further in three places. It works through a five-year cost model with every assumption on the table, so you can swap in your own numbers. It shows how lock-in follows you to a custom build if you aren’t careful. And it ends with a scoring sheet you can fill in with your team in under an hour.

The difference in one table

Off-the-shelf software (also called COTS, or simply SaaS today) is one product sold to thousands of companies with the same feature set. Custom software is built for one organization, around its own workflow, data and rules. Here is how they compare on the things that tend to decide the outcome:

Read the last row twice. Most comparisons treat lock-in as a SaaS problem only. It isn’t, and we’ll come back to it.

Off-the-shelf wins more often than agencies admit

We build custom software for a living, and we still tell a fair number of prospects to buy something instead. Accounting, payroll, email, chat, a standard CRM, ticketing, e-signature: these are solved problems. Vendors have spent years and millions of dollars on edge cases you haven’t hit yet, such as tax rule changes, accessibility, audit logs and SSO. Rebuilding any of that is paying to reinvent something you could rent for a few dollars per user.

Buying also wins when the process itself is still moving. If your sales process changed twice last quarter, a configurable tool absorbs that churn better than a codebase does. A custom system built around a process that’s still being invented bakes the wrong assumptions into the data model.

Off-the-shelf is the right default when:

• the function is the same in your company as in your competitors’ (nobody chooses you for your payroll process);
• you need it working this month;
• the vendor’s standard workflow is at least 80% of what you do, and you can live with changing the other 20%;
• nobody on your side will own a system after it launches.

When custom software earns its cost

Custom starts to pay when the software stops being support for the business and becomes part of how the business makes money. Think of a logistics firm whose dispatch rules are its margin, a lender whose underwriting flow is the product, or a SaaS company building the platform it sells. Forcing any of them into a generic tool means giving away the thing that sets them apart.

The second trigger is less glamorous and far more common: the workaround tax. It shows up as exports to spreadsheets, copy-pasting between two systems, a person whose unofficial job is reconciling the CRM with billing, and three tools stitched together with brittle automations. You’re already paying for a custom system at that point. You’re paying in staff hours, errors and delay, and none of that appears on the software invoice.

Custom also makes sense when:

• your data can’t leave a specific region or system for compliance reasons, and no vendor offers that at a sane tier;
• you need an integration the vendor doesn’t support and won’t prioritize;
• the per-seat model breaks your economics (for example, thousands of occasional external users such as customers, drivers or field staff);
• you’re building a product to sell, not a tool to use.

The costs nobody puts in the first comparison

The first comparison usually puts a subscription price next to a build quote. Both numbers are incomplete.

On the off-the-shelf side, the subscription line grows. Vertice, which tracks software purchasing across its customer base, measured SaaS price inflation at 16.4% in June 2026, the highest monthly rate in its records. That’s one platform’s transaction data, not a market-wide index, but the direction matches what finance teams report at renewal. The same source found that 28% of SaaS contracts renewed in Q4 2025 delivered less value without a lower price, because features moved to higher tiers or into paid add-ons.

Then there are seats nobody uses. Zylo’s analysis of over 40 million licenses found that organizations leave an average of 36% of their SaaS licenses unused against recommended utilization levels. Some of that is fixable with better license hygiene. Some of it is the price of buying in tiers and bundles.

The largest hidden cost is integration. The 2025 MuleSoft Connectivity Benchmark reported that the average enterprise runs 897 applications, but only 29% of them are integrated, and IT teams spend 39% of their time building custom integrations. Buying a tool rarely ends the build work. It moves the work to the edges, where it’s harder to see and harder to maintain.

On the custom side, the build quote is the smallest part of the long-term bill if nobody plans for what comes after. A live system needs hosting, monitoring, security patches, dependency upgrades, backups that are actually tested, and someone who understands the code when something breaks. A common planning assumption is 15–20% of the original build cost per year for keeping a system healthy, before any new features. Treat that as a starting estimate to challenge, not a law.

There’s also a people cost. If one contractor wrote the system and only that person understands it, you’ve swapped a vendor dependency for a single-person dependency, and a single person can leave faster than a vendor can.

A 5-year cost model you can copy

Price comparisons fail because they compare year one to year one. The honest comparison runs over three to five years and counts time, not just invoices. Below is a worked example. Every number is an illustrative assumption, not a quote. Replace them with your own.

Shared assumptions

• Off-the-shelf: 30 seats at $55 per user per month, plus $7,200 a year for an integration middleware plan. That’s $27,000 in year one, rising 10% at each annual renewal.
• Custom: a $120,000 build that takes five months, during which the SaaS stays in use. Running costs are 18% of the build per year ($21,600), covering hosting, monitoring and maintenance.
• The custom system removes 80% of the manual workaround time. It won’t remove all of it.
• Staff time is costed at $45 per hour, over 48 working weeks.

The only thing that changes between the two scenarios is how much manual work the current tool creates.

The subscription price barely matters here. In both scenarios the SaaS costs about $165,000 over five years. The decision flips on hours, the workaround time that never shows up on an invoice.

So before you debate vendors or request build quotes, measure one thing for two weeks: how many hours per week people spend exporting, re-entering, reconciling and fixing data because the current tool doesn’t fit. If you can’t measure it, estimate it with the people doing the work, not their managers.

Two caveats keep this honest. First, custom year one is the most expensive year by far. The cash goes out before the savings arrive, and a 20% overrun on the build moves the break-even point out by a year or more. Second, the model assumes the build is scoped well. A fixed, written scope is what makes the custom column a number instead of a hope.

Lock-in doesn’t disappear when you build. It moves.

SaaS lock-in is well understood. Your data sits in someone else’s schema, the export may be partial, contracts auto-renew, and the price at renewal is whatever the vendor thinks you’ll tolerate given the cost of leaving.

Custom lock-in gets talked about less, and it can be worse. It happens when the repository lives in the agency’s account, when production infrastructure is billed to them, when there’s no documentation, or when the stack is so unusual that only the original team can hire for it. You own the software on paper and can’t touch it in practice.

Ask these questions whichever way you go:

This is why our own engagements hand over the repository, the infrastructure and the documentation, and why the operations agreement after launch can be ended with 30 days’ notice. We’d rather be kept because the system runs well than because leaving is painful. Whoever you work with, get those terms in writing before the first line of code.

The middle options most comparisons skip

“Build or buy” suggests two doors. In practice there are at least four:

1. 01Configure. Use the off-the-shelf tool’s own settings, custom fields and workflow rules. Cheap and reversible. This is where to start.
2. 02Extend. Add small pieces on top through the vendor’s API or low-code tools, such as a sync job, a custom report or an approval step. Good for closing a gap of one or two workflows.
3. 03Build the edge, buy the core. Keep a standard system of record (accounting, CRM) and build the part that makes you different as a separate application that talks to it. This is the most common right answer for growing companies.
4. 04Build the core. Replace the system of record entirely. This makes sense when the core itself is the product or the constraint.

Each step up costs more and gives more control. Move up only when the step below has visibly stopped working, and when you can point to the hours or revenue it’s costing you.

When the answer is “neither, not yet”

Sometimes the right move is to delay the decision on purpose. If the process is still changing monthly, if fewer than a handful of people use it, or if a well-organized spreadsheet genuinely does the job, don’t buy a platform and don’t commission a build. Write the process down, run it manually for a quarter, and count where the time goes. You’ll make a better decision with that data, and you’ll have the requirements document you’d need anyway.

A scoring sheet for your team

Fill this in with the people who run the process, not only the people who approve the budget. Score each line from 1 to 5, multiply by the weight, and add it up.

The maximum is 70. Under 30: buy, and configure before you customize. 30 to 45: hybrid, so buy the core and build the edge. Over 45: a custom build is worth scoping properly. If “stability” or “capacity to own” scores 1, fix that before building, whatever the total says.

What to have ready before you ask anyone for a quote

A quote given without discovery is a guess, whether it’s a vendor’s implementation estimate or an agency’s build price. Before you compare numbers, have these ready, or pay someone to produce them:

• a written map of the process as it actually runs today, including the workarounds;
• the list of systems it touches, and what data moves between them;
• who uses it, with which permissions;
• any compliance, retention or data-location rules;
• what “done” means in measurable terms, such as hours saved, errors removed or turnaround time.

This is the core of the discovery stage in how we structure every engagement: the output is a requirements document, a written scope and a fixed budget, before any code is written. Even if you end up buying a SaaS product, that document will help you judge demos and ask vendors the right questions. If you do go the subscription route, our piece on how SaaS changes operating costs covers what to plan for.

The decision rule

Buy what’s standard and configure it before you customize it. Build what makes you different, or what’s costing you more in hours than the license costs in dollars. Whichever you choose, own your data and your exit terms from day one.

If you’ve run the scoring sheet and landed in the hybrid or build range, send us the process and the shortlist you’re weighing. We’ll tell you which side we’d take and why, and if the answer is “buy”, we’ll say that too. You can also see the systems we’ve built and what we build end to end.