What does custom software actually cost?
Key takeaways
Most software is sold by the hour, which puts all the risk on you. What actually drives the cost, what to expect to pay, and the six things to ask for before you commit.
People ask "how much does custom software cost?" and get one of two answers: a day rate, or a discovery call. Neither tells you what you actually want to know, which is what this specific thing will cost you before you commit to it.
Here is the honest version.
Why nobody will give you a straight number
Most software is sold by the hour or by the day. That is not a conspiracy, it is a hedge: the developer does not know how long your job will take, so they sell you time instead of an outcome and let the total land where it lands.
The problem is that it puts the entire risk on you. If the work takes twice as long as expected, you pay twice as much. If it turns out to be simpler, the hours somehow still get used. You are buying an unknown quantity of an unknown thing, and the only person who can see the meter is the one being paid by it.
The day-rate range in the UK runs roughly from £250 for a junior freelancer to £1,200 and up for an agency team. That range is close to useless for planning, because it tells you nothing about how many days.
What actually drives the cost
Four things, in order of impact.
How clearly the job is defined. This is the big one. "Add a discount code field to the checkout" is a small, knowable job. "Improve the checkout" is not a job at all, it is a conversation. Most cost overruns are not slow developers, they are unclear scope discovered halfway through.
Whether the software already exists. Changing something is usually cheaper than building it, but not always: a well-built system is easy to extend, and a fragile one can make a small change expensive. Anyone quoting a change without looking at the code is guessing.
How many places the change touches. A new field on a form sounds small. If that field has to appear on a report, an export, an email and a mobile app, it is four jobs wearing one coat. Ask "where else does this show up?" before you accept any estimate.
Integrations you do not control. Anything talking to a payment provider, an accounting system or a courier depends on somebody else's API and somebody else's rules. That is not a reason to avoid it; it is a reason to expect the estimate to carry more uncertainty than the rest.
What you should expect to pay
Some rough anchors, and they are anchors rather than quotes.
- A small change to something that already works, like a new field, a copy change, a report column: usually a few hours of work. If someone quotes days for this, ask what else they are including.
- A self-contained feature, like an export, a new form with validation, a scheduled email: typically a few days.
- A small application that does one job well, with a handful of screens: usually a few weeks.
- A full bespoke system with users, permissions, reporting and integrations: months, and it should start with a written specification before anyone writes code.
The numbers that matter are not the day rates. They are: what is the total, when do I know it, and can it change without my agreement.
How to buy it without getting stung
Six things to ask for, all of which a reasonable supplier will say yes to.
- A fixed price for a defined piece of work. Not an estimate, a price. If the scope is too vague to price, that is information: the next step is defining it, and that itself can be a small paid piece of work.
- The price before the work, in writing. Approving the price should be the thing that starts the job.
- What happens if it turns out to be bigger. The honest answer is "we come back and tell you before we do it", not "we bill the extra".
- Who owns the code. The answer should be you, in your repository, on your hosting, in your accounts. This matters more than anything else on this list and almost nobody thinks to ask.
- What you are not getting. Hosting? Support? Bug fixes for how long? Silence here is where the second invoice lives.
- Whether you can stop. A supplier who needs you locked in for twelve months is telling you something about their pipeline, not about your project.
When you do not need to pay anyone
Genuinely: if the change is content, a setting, or something your existing system already does and nobody has shown you, do not hire a developer. Ask whoever built it, or search the documentation for the product. Plenty of "we need a developer" jobs turn out to be a checkbox in an admin panel.
Equally, if you need a developer sitting with your team every day for the next year, you need to hire someone, not buy jobs from a supplier. That is a different purchase and anyone telling you otherwise is selling.
The part that needs a developer
Working out what the job actually is, and what it will cost, needs someone who can read the code. That is the bit you cannot sensibly do yourself, and it is where a good supplier earns their place: not by being cheap, but by telling you the real size of the thing before you spend anything.
If you would rather skip the estimating entirely, tell us what you need and we will come back with a fixed price. It takes about a minute, there is no call, and you are not committed to anything by asking.
What to do next
Write down the change you want in one sentence, as if you were explaining it to a colleague. If you can do that, it can be priced. If you cannot, the first job is working out what you are actually asking for, and that is worth doing before anyone quotes you.
Our rates are published on the one-off jobs and ongoing work pages, so you can see them before you talk to anybody. You approve a fixed price before any work starts, so the bill is never a surprise, and the code is yours from the first day.