How much does custom software cost?

Why published ranges are useless

You'll find pages quoting $10,000 to $500,000 for custom software. That's true and it's worth nothing to you.

The range is that wide because the words cover completely different objects. Joining two systems you already own is a small job. A platform with roles, permissions, an audit trail and a mobile app is not, and both get called custom software.

A number is only meaningful next to a description of what it buys. When you see one without that, skip it.

Here, builds start at $5,000, with a fixed price agreed before the build begins. Automation on its own is often less. Larger or more custom projects are quoted separately.

Seven things that move the number

Roughly in order of how much they move it. Two projects that sound identical can be far apart on these.

• How many people use it, and whether they see the same records. One person doing one job is straightforward. Forty people across three roles, each seeing only what they should, is a different build.
• What it connects to. Nothing is easy. Four systems that each describe a customer differently is most of the work, and it's the part that gets underestimated.
• Whether data has to move. Starting empty is simple. Bringing fifteen years of records out of an old system, in a state anyone can trust, is its own project.
• Who's allowed to see what. Permissions sound like a checkbox and behave like a feature.
• Whether money runs through it. Payments, invoicing, tax and payroll all bring rules, records and a much higher cost of being wrong.
• Whether it works without signal. An office is easy. A basement, a van or a rural site means it has to work offline and reconcile later.
• How it looks. This one is real, and it's the smallest of the seven. Plain and clear is quick. Matched to your brand takes longer.

What a quote has to cover

Anything missing here is a cost that turns up later on a separate invoice.

• A fixed price for the whole build, agreed before anything starts.
• Who owns the code, the data and the accounts at the end. This should be you, in writing.
• What happens when it's wrong. Support, and for how long.
• Hosting and running costs, named, with a monthly figure.
• What isn't included. The most useful line in any quote and the one most often absent.
• What it does when the other system is down. Anything connecting to something else needs an answer here.

The running costs

The build price isn't the whole picture and this is where budgets get caught out.

• Hosting. A few dollars a month for something small, more for anything with real traffic or large files.
• AI, if it uses any. Billed per use, so it moves with your volume. Model it at three times today's volume before you commit.
• Changes. Budget something. A business that never changes its software has usually stopped changing.
• The odd fix. The systems it connects to will change and something will need adjusting. This is normal and it should be discussed up front.

How to tell whether a number is fair

Set it against what the problem costs you now. That's the only comparison that means anything.

Four people losing twenty minutes a day to a workaround is about 340 hours a year. Put your own number on an hour and you have something to hold a quote against.

Then look at the shape of the quote instead of the total. A fixed price with a clear list of what's in it and what isn't is a good sign. An hourly estimate with no ceiling is a signal that nobody has worked out what's being built, and you'll be paying to find out.

And be wary of the cheapest quote when it's much cheaper. Software that's badly built costs more over three years than software that's expensive, because everything after the first version is slower, and you usually can't tell which you bought until month six.