Custom Software vs Off-the-Shelf: An Honest Guide

Somewhere around the fourteenth software subscription, most businesses have the conversation. The team runs on a stack of tools that each do eighty percent of a job, the gaps are bridged by spreadsheets and a person who "knows how the system works," and someone finally asks: should we just build our own?

Both answers come with a sales pitch attached. Custom development shops will tell you off-the-shelf software is a treadmill of fees. Software vendors will tell you custom projects fail spectacularly and often. Since we build custom software for a living, you know our bias, so we will hold ourselves to the same standard as the rest of this blog: real numbers with real sources, including the ones that cut against us.

First, clear out the folklore

You have probably heard that most software projects fail. The famous numbers do not survive contact with their own citations.

The "70 percent of projects fail" line traces back to a 1993 book on business reengineering whose authors called it, in their own words, an unscientific estimate; one of them publicly disowned the number within two years, and researchers who followed the citation trail found every reference leads to another reference with no measurement at the bottom. The other pillar, the Standish CHAOS reports claiming only a sixth of projects succeed, was taken apart in IEEE Software: Standish defined success purely as matching the original estimate, so a project that delivered enormous value slightly late counted as a failure, and a padded estimate counted as success. The report series itself stopped publishing after 2020.

What does credible data say? Research covering 1,471 IT projects found the average cost overrun was a modest 27 percent. The catch: about one project in six became what the researchers called a black swan, averaging roughly 200 percent over budget. Most projects land close to plan; a fat-tailed minority blows up. That reframes the whole build-or-buy risk question: the danger is not "custom software usually fails," it is "large, sprawling projects occasionally fail catastrophically." The mitigation is boring and effective: keep the project small, ship in stages, and never bet the company on a big bang.

What off-the-shelf really costs over five years

The subscription model's price tag is a moving target. Analysis of actual SaaS transaction data has measured software price inflation running at 11 to 12 percent per year, several times general inflation, with most vendors obscuring increases inside plan changes and repackaging. License waste compounds it: studies of software portfolios consistently find a large share of purchased licenses sitting unused, and while that research skews toward larger companies, any owner who has counted logins against seats knows the effect personally.

Then there are the costs that never appear on an invoice: the hours spent working around the missing twenty percent, the spreadsheet glue between systems that do not talk, the feature your workflow depends on that the vendor deprecates in the spring release, and per-seat pricing that turns your growth into their revenue. None of this makes off-the-shelf wrong. It makes the real comparison five-year cost against five-year cost, not sticker against sticker.

What custom really costs

Honesty cuts this way too. Upfront, custom costs more, and the price ranges you see published (fifty thousand to several hundred thousand dollars for typical small business systems) come from development shops' marketing pages, ours included in spirit; treat them as directional until someone scopes your actual project.

The number that matters more is the one vendor blogs mostly skip: maintenance. The best-known research on software lifecycle costs, going back to Robert Glass's work, puts ongoing maintenance and evolution at somewhere between 40 and 80 percent of total lifetime cost. Custom software is not a purchase; it is an asset with upkeep, like a building. Any shop that quotes you a build price without discussing what year two looks like is leaving out half the story.

What you get for that: software shaped to your process instead of the reverse, no per-seat meter, no vendor deciding your feature set, and an asset you own. Make sure the ownership is real: your contract should say the code is yours.

When off-the-shelf wins, which is most of the time

The most useful decision rule in this space comes from software architect Martin Fowler's circle: distinguish utility from strategic. Utility functions are things your business must do but that do not distinguish you from competitors: accounting, email, payroll, document storage. For utility, buy the standard tool and adapt your process to it; a custom accounting system makes you exactly zero dollars more than QuickBooks does. Off-the-shelf also wins when you need something running next month, when a regulated domain makes a certified product safer, and when your process is genuinely ordinary.

When custom wins: the process is the business

Build when the process the software supports is the thing that makes customers choose you. The scheduling logic that lets you quote same-day service when competitors quote next week. The pricing engine that took ten years to learn. The workflow that is literally why your margins beat the industry. Custom also earns its keep on integration grounds: when the spreadsheet glue between five systems becomes a full-time job, a purpose-built connector or replacement often costs less than the ongoing friction.

The middle path most businesses actually need

Build-versus-buy is a false binary for most companies. The common right answer is buy the platform, customize the edges: keep the accounting system, the CRM, the ERP, and build the specific pieces they lack, integrated properly. We do a lot of this with NetSuite, where the pattern is well studied: industry research on ERP projects finds nearly every company customizes at least somewhat, and also that heavy customization is where budgets and timelines inflate. The doctrine that works: configure first, script only where the business case is specific, and build so upgrades survive. The same logic bounds low-code tools: excellent for forms and workflows, wrong for anything with demanding logic or performance.

Eight questions before you talk to any vendor

1. Is this process utility, or is it why customers pick us?
2. What does our current tooling truly cost per year, including the workaround hours?
3. What would the smallest useful version of a custom fix be?
4. Could we ship it in stages, each one valuable on its own?
5. What does maintenance look like in year two and who pays for it?
6. Who owns the code?
7. What breaks if the vendor triples the price or sunsets the product?
8. Have we priced customizing what we already own?

If the answers point at custom, keep it small and staged, and the black swan math stays on your side. If they point at off-the-shelf, buy with your eyes open about the five-year cost. And if they point at the middle, that is normal; it is where most of our consulting engagements start, and often the first conversation is with a fractional IT lead who can referee build-versus-buy without a product to sell.

Frequently asked questions

How much does custom software development cost in Canada?

Published ranges for small business systems run from tens of thousands into the hundreds of thousands of dollars, but they are marketing numbers until someone scopes your project. The honest way to buy: define the smallest useful version, get a fixed quote for that, and require the maintenance picture in writing.

How long does it take to build custom software?

Small-business-scale systems typically take three to nine months to a first working version, with complex builds running longer. Staged delivery matters more than the total: you should be using something real well before the end date.

Is custom software worth it for a small business?

Sometimes, and less often than developers imply. It is worth it when the process it supports is your competitive edge or when integration friction between existing tools has become a real labour cost. It is rarely worth it for utility functions like accounting or email.

Who owns the code when we pay for custom software?

Whatever the contract says, which is why the contract must say you do. Insist on ownership or a perpetual, irrevocable license, plus delivery of source code and documentation. A shop that resists has told you something useful.

Can we customize off-the-shelf software instead of building from scratch?

Usually yes, and it is often the right answer. Most business platforms support configuration and scripted extension. The discipline is to configure first, customize only with a specific business case, and build customizations so vendor upgrades do not break them.