Hourly Rate or Fixed Price? How Bespoke Software Is Billed

Bespoke software in the UK is billed in one of two ways: a fixed price for an agreed specification, or time and materials, where you pay an hourly or day rate for the hours actually worked. Neither is automatically cheaper. A fixed price moves the risk of being wrong onto the developer, who charges for carrying it. Hourly billing leaves that risk with you, but you only pay for what gets built, and you can change your mind along the way.

I bill time and materials, because it is the better fit for most bespoke projects. This post sets out why, where fixed price is the more sensible choice, and how to keep hourly billing under control. If you want to know what a project is likely to cost rather than how it is billed, read How Much Does Bespoke Software Cost in the UK? first. It gives typical price bands by project size.

How Fixed-Price Software Quotes Work

A fixed price looks like certainty. You agree a specification, the developer names a figure, and that is what you pay. For the buyer it is easy to approve and easy to budget. The costs are real, though. They are just harder to see.

The risk premium

Every software estimate is a guess about work nobody has done yet. When a developer commits to a fixed figure, they are betting that the guess holds. A sensible developer protects themselves by adding a margin, and the more unknowns the project has, the bigger that margin needs to be. If the project goes smoothly, the margin is profit. You paid for contingency that was never used, and you have no way of knowing how much of the quote it was.

The specification has to come first

You cannot fix a price against a vague idea, so fixed-price work starts with a detailed specification: every screen, rule and report written down before anything is built. That document takes real time to produce, on both sides, and it is written at the point when you know least about what you need. Much of it will be revised as soon as you use the first working version.

Change-request friction

Requirements change once people see working software. They always do. Once the specification is the contract, each change becomes a change request: raised, estimated, priced and approved before any work starts. Small improvements get held up in paperwork, or get dropped because they are not worth the argument. The relationship becomes a negotiation about what the document said, not a conversation about what the business needs.

The pressure to cut corners late

This is the least talked-about cost. If a fixed-price project runs over, the developer is working at a loss. The easiest places to recover the time are the ones you will not notice until later: thinner testing, error handling that covers only the obvious cases, a feature built to the letter of the specification rather than to what you meant. None of this needs bad faith. It is simply where the incentives point in the last few weeks of an overrunning job.

How Time and Materials Billing Works

With time and materials, you pay for the hours the work takes, at an agreed hourly or day rate, and the hours are reported to you. The trade-off is the reverse of a fixed price.

What you gain

• Transparency. You can see what the time was spent on. On my projects, hours are tracked and invoiced transparently.
• You pay for what is built. There is no contingency margin in the price. If a feature turns out simpler than expected, it costs less.
• You can change direction. When the first working version shows that a screen should work differently, or that a report nobody asked for is the one that matters, you change it. No renegotiation.
• Less time on paperwork up front. You still need a clear understanding of the problem, but not a full specification that tries to predict every detail before anyone has seen the software.

What you take on

The honest downside is that you carry more of the variance. If something takes longer than estimated, because an integration's API behaves differently from its documentation or the data migration turns out messier than anyone thought, you pay for that time. Under a fixed price the developer would have absorbed it, having already charged you for the possibility. Time and materials is a better deal on average, but a wider range of outcomes, and you need to manage it.

How much change time and materials can absorb is best shown by Colehill Customs, a van conversion business whose production planner had forty-seven releases in five weeks. The client sent screen recordings of her own working week, and most changes went live the same day they were asked for. Very few of those changes were foreseeable at the start, and under a tightly specified contract each one would have been a change request.

How to Manage the Risk of Hourly Billing

The fear with hourly billing is the open cheque. That is a real risk, and it is managed with a few simple controls. Whoever you work with, ask for these.

Start with a smaller first phase and an estimate

Do not commit to the whole system on day one. Pick the part that removes the most pain, get an estimate for that smaller first phase, and see how the estimate compares with what it actually took. You get useful software early, and you find out how well your developer estimates before you have committed the larger budget. This is how I prefer to start when the full scope is uncertain.

Regular demos of working software

Progress should be something you can click through, not a status report. On my projects development happens in short cycles with regular demos, so you see progress every week and can steer before hours are spent in the wrong direction.

Time reporting you can read

The hours on an invoice should map to work you recognise. If a line says "development, 30 hours" with nothing else, ask for more. Detailed time reporting is the thing that makes time and materials trustworthy. Without it you are back to trusting a number.

A cap or budget for each phase

Agree a budget for each phase and a point at which work stops for a review if it is going to be exceeded. That gives you most of the certainty of a fixed price without the risk margin. If the phase is running over, you decide whether to carry on, cut something, or stop, rather than finding out at the end.

For ongoing work after launch, the same principle applies. Support and new features are billed on time and materials as needed, with no mandatory maintenance contract. Where there is a predictable volume of work, a monthly allocation can be agreed for budget certainty.

When a Fixed Price Is Reasonable

Fixed price is not a con. It is the right model when the uncertainty is low, because then the risk margin is small and the price is a fair reflection of the work. Good candidates are:

• A single, well-defined report or export
• An integration against a documented, stable API
• A data migration where the source, target and rules are all known
• A change to an existing system that the developer already knows well

The warning sign is a fixed price on a large project that has not been built before. The bigger and newer the project, the bigger the margin, the thicker the specification and the more change requests you should expect.

What About Cost Calculators?

Many people search for a bespoke software cost calculator. The trouble is that the things that drive the cost of bespoke software (business rules, the state of your existing data, the quirks of the systems it has to connect to) are exactly what a form cannot ask about. A calculator gives you a number with false precision. The price bands in the cost guide are a more honest starting point, followed by a short conversation about what your system actually needs to do.

Why the Billing Model Matters Beyond the First Project

Bespoke software is rarely finished. The business changes, and the software changes with it. A billing model built around change requests makes every one of those changes harder. Time and materials, with clear reporting, makes them routine. That is a large part of why some of my client relationships have lasted for decades. Weald IT has worked with me for more than 25 years, and their system has been modernised steadily over that time rather than rebuilt in one go. I have written more about this in why clients stay for decades.

You can see how the rest of my working model fits together on the services page. In short, you talk directly to the developer who writes the code, and there is no padded fixed price.

Frequently Asked Questions

Is bespoke software usually billed by the hour or at a fixed price?

Both models are common in the UK. Fixed price means one agreed figure for an agreed specification. Time and materials means you pay for the hours actually worked, usually at an hourly or day rate, with the time reported as it goes. Most small and medium bespoke projects are better suited to time and materials, because the requirements change once people see working software. Small, tightly specified jobs are the exception, and a fixed price can suit them well.

Why do fixed-price software quotes cost more?

A developer quoting a fixed price carries the risk of being wrong, so the quote includes a margin to cover it. On a project with genuine unknowns that margin has to be generous. If the work goes smoothly, you have still paid for the contingency. The price also has to cover the time spent writing a specification detailed enough to quote against, and the cost of managing change requests later.

Isn't hourly billing an open cheque?

It can be if nobody manages it. The controls are straightforward: start with a smaller first phase and an estimate for it, see working software at regular demos, get time reported in enough detail to see where the hours went, and agree a budget for each phase with a point at which you stop and review. With those in place you can see the spend building up week by week, rather than finding out at the end.

When is a fixed price the right choice for software?

When the work is small and well specified: a defined report, a single integration against a documented API, a data migration with a known source and target, or a change to a system the developer already knows well. In those cases the uncertainty is low, so the risk margin is small and the fixed price is a fair reflection of the work.

Is there a reliable bespoke software cost calculator for the UK?

Not one that gives a figure worth budgeting against. A calculator can count features, but the cost of bespoke software is driven by business rules, data quality and integrations, and those only come out in conversation. Typical UK price bands by project size are a more honest starting point, followed by a short call about your actual requirements.

How does SWF Consultancy bill?

Time and materials. You pay for the time the work takes, with the hours tracked and invoiced transparently, and there is no padded fixed price. For a new project the usual starting point is an estimate for a smaller first phase. Support and later development are billed the same way, with no mandatory maintenance contract. Get in touch to talk through your project.