---
title: Build vs buy for small-business software
description: What custom software really costs over five years, when a spreadsheet is honestly fine, and the narrow cases where building wins.
date: 2026-03-23
updated: 2026-03-23
tags: [software, small business]
url: "https://joshdargie.com/blog/build-vs-buy-small-business"
author: Josh Dargie
---

Every few months a small-business owner tells me they're thinking about getting "an app built." Sometimes it's a good idea. Most of the time, what they actually need already exists for a modest monthly fee, or is already sitting in a spreadsheet that works fine and just needs a bit of discipline.

I've built software for a living and I've run platforms that hosted thousands of other people's software, so I don't say this as someone allergic to code. I say it as someone who has watched the full life cycle, including the part nobody puts in the proposal.

## The quote is the down payment, not the price

Custom software has a purchase price and a carrying cost, and the carrying cost is the one that sinks people.

The build quote covers version one. It does not cover the security patches, the server it runs on, the fixes when a browser update breaks the layout, the changes when your business changes, or the awkward conversation when the developer who built it moves on and nobody else wants to touch their code. A sensible planning number is that every year of ownership costs a meaningful fraction of the original build, year after year, forever. Off-the-shelf software has carrying costs too, but they're spread across thousands of customers and printed on the pricing page where you can see them.

So the honest comparison is never "custom build vs subscription." It's five years of each, including the boring years.

## When a spreadsheet is honestly fine

Some problems don't deserve software at all yet.

If one or two people touch the data, the volume is a few dozen rows a week, and nothing updates in real time, a well-organized spreadsheet is a legitimate tool, and I'll tell you so even when it costs me a project. The [keep what you have](/blog/keep-what-you-have) principle applies to software as much as hardware: a boring thing that works beats an impressive thing you now have to maintain.

The spreadsheet stops being fine when you see specific symptoms: two people overwriting each other's changes, a "final_v7" file culture, manual copying between systems every week, or one person who is the only one who understands the tabs. Those are signals to move up, not reasons to feel embarrassed.

## When off-the-shelf wins, which is usually

For accounting, invoicing, scheduling, payroll, email, e-commerce, and CRM, the buy decision is nearly automatic. These are solved problems. Thousands of businesses shaped like yours have already funded a decade of refinement, and you get all of it for a subscription that costs less per year than a single week of custom development.

The trap here is a different one: buying software and then paying to customize it until it's effectively custom anyway. If a product needs heavy modification before it fits, that's usually a sign it's the wrong product, and it's worth [scoping the actual requirement](/blog/project-scoping) properly before signing anything. Change your process to fit good software before you pay to bend software around a shaky process.

## When building actually pays

Custom makes sense in a narrow band, and it's worth naming it precisely: when the software is your competitive advantage, not your plumbing.

If the thing you'd build is how you win customers, price work, or deliver something nobody else delivers, owning it can be worth every dollar of carrying cost. The same goes for genuinely odd workflows that no vendor serves, though I'd want to see the failed search for an existing product first. And sometimes the right build is tiny: a small integration that glues two off-the-shelf systems together often delivers most of the payoff of a big custom build at a twentieth of the cost and risk.

What almost never pays is rebuilding plumbing. A custom-built invoicing system is a liability with your logo on it.

## The five-year test

When someone brings me a build-vs-buy decision, I make them write down both options as five-year numbers: licences and subscriptions on one side; build cost, hosting, maintenance, and the cost of replacing the developer on the other. Then I ask who fixes each option at 9 p.m. on a Friday. The answer usually becomes obvious before I've offered an opinion.

If you're staring at this decision now, it's cheap to get it checked before it gets expensive to unwind. [A planning session](/hire#planning) with someone who has no software to sell you tends to pay for itself in the first hour.