Custom software for a small business usually runs between a few thousand, if it's a narrow tool that solves one specific task, and tens of thousands, if it's a full system that replaces several programs and touches the whole company. The range is that wide because the price isn't set by the technology, it's set by scope: how many things you want it to do and how many people it affects. Two businesses ask for "a management program" and one needs something for three thousand and the other for forty thousand.
Before asking for a quote it helps to understand what moves that figure, because it's almost always in your hands to bring it down: you bring it down by cutting scope, not by haggling over hours.
What are you actually paying for?
You're not paying for the code. You're paying for understanding your problem, deciding what gets built and what doesn't, building it, migrating your data from wherever it lives today, teaching your team to use it, and fixing whatever comes up in the first months. Typing out the program is one part; often the smallest. What swells an honest quote is everything around the program that makes it actually get used.
So when someone gives you a very low price, the question isn't "how do they do it so cheap", it's "what have they left out". Usually they've left out migration, training and maintenance, which are exactly what makes the program work in your company and not just on their computer.
What pushes the price up?
Four things, almost always the same ones:
- Scope. A tool that does one thing costs little. A system that handles quotes, orders, stock and invoicing all at once costs a lot, because it's four programs in one.
- Connections. If it has to talk to your accounting program, your bank or your online shop, each connection is separate work and a separate point of failure.
- How many people use it and how. A tool for you isn't the same as a system for twenty people with different permissions, each seeing their own part.
- What you don't know you want. The requirements that appear halfway through. They're legitimate, but each one moves the figure. That's why scoping well at the start matters.
Notice none of these is "what technology it uses". The technology almost never drives the price; scope does.
How do you budget without a nasty surprise?
With a simple rule: don't buy the whole system at once. Break it up and start with what hurts most.
- Write down the one concrete problem you want to solve first. Not "modernise the company", but "stop doing quotes by hand". One problem, not a list.
- Ask for a quote on just that part. The smallest piece that already helps you. That way you see a real price and check whether whoever's going to build it understands you.
- Require the quote to separate line items. Build, data migration, training and maintenance on different lines. If it's all one figure, you don't know what you're buying.
- Put it to work and decide the next piece with data. When that piece works, you'll know whether the next one is worth it. And you already know who you're working with.
Breaking it up costs a bit more in total than doing it all at once, but it saves you the shock of spending forty thousand on something you discover, in the end, wasn't what you needed.
What ranges should you expect, to get a feel?
Without seeing your case there's no price, but there are orders of magnitude that help you know which league you're playing in before you sit down to talk:
| Type of program | What it solves | Order of magnitude |
|---|---|---|
| Narrow tool | One specific task: a form that feeds a spreadsheet, a calculator, a small dashboard | Thousands |
| Single-process app | A whole process end to end: quotes, or orders, or work reports | High thousands to low tens of thousands |
| Management system | Several connected processes, several users, permissions | Tens of thousands |
These are magnitudes, not price lists. They're good for one thing: if someone quotes you a full management system for what a narrow tool costs, something doesn't add up, and it's usually what they've left out.
When is it NOT worth building custom?
Custom isn't always the answer, and saying so is part of budgeting well:
- If off-the-shelf already does 90%. Paying for custom to gain the last 10% rarely beats a subscription that starts tomorrow.
- If your process will change in six months. Building custom on top of something unstable is paying twice. First let the process settle.
- If you won't be able to maintain it. Custom software with no one to look after it ages and gets in the way. If you can't cover that ongoing cost, off-the-shelf is better.
Custom is justified when the way you work is your advantage and no catalogue program respects it. If that's not your case, off-the-shelf is cheaper and arrives sooner.
Frequently asked questions
How much does custom software cost for a small business?
It depends on scope. A narrow tool that solves one specific task can run from a few thousand; a full system that replaces several programs and touches the whole company runs into tens of thousands. What moves the price isn't the technology, it's how much you want to cover.
Why do two quotes for the same thing differ so much?
Almost never because of code quality, but because each understood a different scope. One counts only what you can see; the other includes migrating your data, training your team, fixing bugs and maintaining it. Before comparing figures, line up what each one includes.
Are there costs after the program is delivered?
Yes, and you should count them from the start: hosting, maintenance, small changes as the business evolves, and support. Custom software isn't a one-off purchase, it's something alive. Ignoring that cost is the most expensive mistake.
How do you know if custom software pays off?
With a calculation: hours it saves a month, or sales it helps you not lose, against what it costs to build and maintain. If the saving pays back the build in one or two years, it usually pays off. If you have to force the number, not yet.
Scope rules
The price of custom software is decided by how much it covers, not by the technology. A narrow tool costs thousands; a full system, tens of thousands. And most of what you pay isn't the code, but understanding the problem, migrating data, training and maintaining.
Budget in parts: start with the problem that hurts most, ask for a price on just that piece, and require it to separate build, migration, training and maintenance. That way you compare for real and don't pay for what someone else left out.
Want to know what your specific case would cost?
Tell me the problem you want to solve first and I'll say honestly whether custom or off-the-shelf works out better, and where to start so you don't overspend. If off-the-shelf is enough for you, I'll say so.
See the custom software service Let's talk about your case