The build vs buy math for small business software

What does custom software development for small business actually cost?

Custom software development for small business is priced by scope and duration, not by ambition, so the honest answer starts with a benchmark and then subtracts from it. The average software development project costs $132,480 and takes about 13 months¹, a figure lifted by enterprise scale work that no small company should read as its own quote. Developers on that same benchmark charge $24 to $49 an hour on average², so the lever you genuinely control is how many hours you commission, and over how many months.

Three cost lines do most of the damage on a small build, and usually only the first one appears in the proposal.

• The build itself. Design, engineering, testing, deployment. This is the number vendors quote and the number owners fixate on.
• Integration and data. Pulling records out of the tools you already pay for, mapping them, keeping them in sync. Underestimating this is the most common reason a fixed quote stops being fixed.
• Year two onward. Hosting, security patching, dependency upgrades, support, and the changes the business will ask for within a fortnight of launch.

That third line is what off the shelf cost guides bury inside a single headline price. Total cost of ownership is the build cost plus every year of running it, and a build you can afford in year one becomes a build you resent in year three when nobody priced the maintenance retainer. Ask for it as a separate, named line before you sign anything. Our guide to the software development life cycle sets out where each of those costs lands across the delivery stages.

Build vs buy: what are you actually comparing?

Most owners set the comparison up wrongly. It is rarely one custom application against one off the shelf product. It is one custom application against the stack of overlapping subscriptions currently holding a workflow together, plus the staff hours spent re-keying data between them.

The subscription side of that ledger leaks more than it looks. Across surveyed organisations, 52.7% of purchased SaaS licences sit unused⁵, and 41% of small business owners report their software costs rising⁸. Teams have started acting on it: 35% have already replaced at least one bought tool with something they built, and 78% expect to build more in 2026⁶.

The comparison that matters is not custom software against one product. It is one custom tool against the stack of subscriptions it would retire.

Budgets are moving in the same direction. 71% of small businesses increased their overall technology budget in 2024 compared with 2023, and only 8% decreased it⁷; the remaining 21% is the calculated balance who held flat⁷. More money is going in either way. The open question is whether it goes into licences you may not use or into an asset you own.

Why do custom builds miss their budgets?

Because most of them do, and pretending otherwise is how small businesses get hurt. 46% of custom software builds run roughly twice over budget, only 8% ship on time, and only 11% stay on budget³. A large company absorbs an overrun of that size. A small team reprices its year around it.

The failure usually predates the first line of code. 67% of failed software implementations trace back to an incorrect build versus buy decision⁴, taken in a meeting before any developer was briefed. Either the team commits to building something a mature product already does well, or it licenses a product that will never fit the one process its margin depends on.

The fix is contractual rather than technical. Break the work into milestones with fixed scope and fixed price, each shippable on its own, and make the second milestone conditional on the first landing as agreed. That converts an estimate you have to trust into a series of decisions you can stop.

How do you run the build vs buy math?

Over three years, both columns, nothing left off. A twelve month comparison flatters the subscription and punishes the build, because the build front loads its cost while the licence spreads it thinly enough to feel harmless.

1. Inventory the current stack. Every tool the workflow touches, its annual cost, and how many seats are genuinely in daily use. The unused seats are the first line of your build budget.
2. Price the manual work. Hours per week spent moving data between those tools, multiplied by loaded salary. This is the cost that never appears on an invoice, and it usually decides the answer.
3. Get the build quoted in two parts. Delivery, then annual run cost. Refuse a single blended number.
4. Add exit costs to both sides. Migrating off a product you outgrow, or picking up a custom tool whose vendor disappears. Establish who holds the code and the repository access on day one.
5. Compare the totals, then apply the tie breaker. When the numbers land close, build what is specific to how you make money and buy everything generic.

Payroll, accounting, email and CRM are almost always buy decisions. The quoting rule only your team understands, the scheduling logic your competitors get wrong, the client portal your customers judge you by: those are where a build earns its keep. When the tool is customer facing, treat it as part of your web platform rather than as an internal utility.

Does AI change the custom software cost equation?

It moves the breakeven point earlier. AI assisted development is reported to be cutting delivery time and cost by roughly two to three times, turning a build of about ten months and $100,000 plus into something closer to three months and $30,000⁶. Treat that as a directional claim from a vendor survey rather than as a quote you can hold anyone to. The direction still matters: every reduction on the build side pulls custom past a stack of recurring licence fees sooner than the old arithmetic allowed.

There is a middle path worth testing first. An industry estimate cited widely in build versus buy coverage puts about 70% of new business applications on low-code or no-code platforms⁹. For a small business, that is a reasonable way to validate a workflow before committing to a full build, provided you check in advance what happens to your data when you outgrow the platform.

When is custom software development for small business the wrong call?

When the process is standard, the product market is mature, and the only real complaint is price. Most small business software should stay bought. Rebuilding accounting software to escape a licence fee converts a predictable annual cost into an unpredictable one that you now also have to maintain.

It is equally wrong when nobody internally owns the software after launch. Custom software needs a named person who decides what changes next, approves the roadmap, and holds the vendor to the retainer. Without that, small defects accumulate, requests go unanswered, and the team quietly drifts back to spreadsheets.

And it is wrong when the timeline is the binding constraint. If a compliance deadline or a customer commitment lands next quarter, buy now, run the build in parallel, and switch when it is genuinely ready.

How do you de-risk the first build?

Start with one workflow, not a system. Pick the single process with the clearest cost attached, build only that, and put it in front of real users. A first release scoped this way costs a fraction of the benchmark project figure, proves whether your team will adopt custom tooling at all, and gives you measured numbers to run the three year comparison again with.

Then interrogate the vendor before the contract rather than after the first invoice.

• Who owns the code, the repository and the hosting accounts on day one?
• What is the annual maintenance cost, quoted separately, for the two years after launch?
• Which milestones are fixed price, and what happens to the schedule if the first one slips?
• Which parts of this are you buying rather than building, and why?
• Who supports the system when the developer who wrote it moves on?

A firm that answers those crisply has delivered small builds before. One that deflects into a technology stack conversation is telling you something too. The discipline separating a build that pays back from one that becomes a liability is scope control, and it starts before anyone produces an estimate. Our engineering practice works to that sequence by default, and if you want a second opinion on your own numbers, tell us what the workflow costs you today.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.