Fixed Price vs Hourly: How to Buy Software Work Without Surprises

Who carries the risk

The real difference between fixed price and hourly is who pays when the work takes longer than planned. With hourly, you do. With a fixed price, the vendor does, as long as the scope stays the same.

That is why fixed price only works with a clear scope. If nobody knows what done looks like, the vendor either pads the price heavily or argues about scope later.

When fixed price makes sense

A fixed price is the right default for most small business projects. It works best when these are true.

• The problem and the result are clear enough to write on one page.
• You have a budget you cannot go over.
• The work has a clear end, like a tool, an integration, or a website.
• You want to compare vendors like for like.

When hourly or monthly is fair

Some work cannot be scoped in advance, and pretending otherwise just moves the risk into a padded number. Time based pricing is fair here, with limits.

• Advisory work, like a fractional CTO, where the questions change month to month.
• A stream of small changes after launch.
• Exploring a messy problem before anyone can scope a build. Here a short, fixed fee discovery or audit is often better than open hours.

A hybrid that works well for small businesses

Many good projects combine the two. A short, fixed fee audit or discovery maps the problem and produces a scope. The build is then quoted at a fixed price against that scope. After launch, upkeep and small changes run on a flat monthly plan with a clear list of what it covers.

This keeps each stage honest. You never pay open hours to figure out what to build, the vendor never guesses at a fixed price, and you always know your monthly cost after launch.

How change requests should work

Every project learns something along the way. A good process treats that as normal. When you or the vendor spot something new, the vendor writes it down, says what it costs and how it affects the date, and waits for your yes before starting. Sometimes the right answer is to swap it for something already in scope at no extra cost.

What you want to avoid is a pile of small extras that show up on the final invoice. If a vendor cannot describe their change process in two sentences, ask them to put one in the contract.

Comparing quotes fairly

Line the quotes up on the same points before you look at the totals.

• Is everything in the brief included in each quote?
• What does each one exclude?
• Who does the work, and how senior are they?
• What does upkeep cost for the first year?
• Do you own the code and data in every case?

Terms that protect you either way

Whatever the model, get these in writing before work starts.

• Scope: what is included, in plain language.
• Exclusions: what is not included. This prevents most disputes.
• Change process: how a new request is priced and approved before work on it begins.
• Payment schedule tied to delivered milestones, not dates.
• Ownership: code, data, and accounts transfer to you once paid, with no license fee.
• Upkeep: what it costs after launch and what it covers.
• For hourly work: a monthly cap and a weekly summary of hours.

Red flags

Walk away, or at least slow down, if you see any of these.

• A fixed price with no written scope. You will meet the scope later, in an argument.
• Hourly with no estimate and no cap.
• The vendor keeps the code or charges a license to keep using your own software.
• Nobody can tell you who will actually do the work.
• A big deposit with nothing delivered for months.

How we do it

We quote projects at a fixed price with a written scope. If we learn something mid project, we adjust scope with you, not the invoice. You own what we build once it is paid. Ongoing work runs on flat monthly plans you can cancel with 30 days notice. Our prices are published so you can check them before the first call.

Questions owners ask