Pay a fixed price when the work can be written down in advance and counted, such as a website with a known list of pages. Pay hourly when the work is open-ended, such as ongoing maintenance or research. Fixed price puts overrun risk on the developer. Hourly puts it on you, in exchange for flexibility.
Every software project starts with the same two questions: what will it cost, and how will that number be decided. The second question shapes the whole relationship, and it gets far less attention than the first.
We send a written plan with a fixed scope before we build anything. That is a choice, and it has costs as well as benefits. Hourly billing is not a trick, and fixed price is not automatically safer. Each one moves risk from one side of the table to the other.
This post lays out both fairly. We do not publish rates, and nothing here is a quote.
What is the difference between fixed price and hourly billing?
Fixed price billing means you pay an agreed amount for an agreed scope of work, however long it takes. Hourly billing means you pay for the time spent, whatever gets done in it. With a fixed price the developer carries the risk of overruns. With hourly billing the client carries it.
That is the whole difference, and everything else follows from it. A developer carrying overrun risk will insist on a clear scope and will push back on additions. A client carrying overrun risk needs visibility into where the hours go.
| Fixed price | Hourly | |
|---|---|---|
| What you agree to | A scope and a price | A rate, and usually an estimate |
| Who carries overrun risk | The developer | The client |
| Final cost known in advance | Yes, for the agreed scope | No |
| Changing direction mid-project | Needs a written change | Easy |
| What it needs to work | A written plan both sides accept | Regular reporting and trust |
| Common failure | Arguments about what was included | A bill larger than expected |
| Suits | Defined projects | Open-ended or ongoing work |
When does a fixed price make sense?
A fixed price makes sense when the work can be described and counted before it starts. A website with a known set of pages, a migration with a known list of addresses, or a tool with a short list of functions can be priced in advance, because both sides can tell when it is finished.
Vortech AC and Electrical is a good example of countable work. The site is 108 pages: each service the company offers in each city it drives to, plus a quote form that reaches the owner directly. A project shaped like that has a clear finish line. The services and cities can be listed before a single page is built.
Fixed price also suits a client who has a budget that cannot move. If the number has to be approved once and never revisited, a fixed scope is the honest way to give that number.
When is hourly billing the better choice?
Hourly billing is the better choice when nobody can say in advance what the work will be. Ongoing maintenance, small requests that arrive unpredictably, investigating a fault in software someone else wrote, and early research on an unproven idea are all poorly served by a fixed price.
Forcing a fixed price onto uncertain work produces one of two bad outcomes. The developer pads the price to cover the unknowns, and you pay for risk that may never arrive. Or the developer prices it thin, runs over, and starts cutting corners you cannot see.
For small ongoing work, hourly is often simply cheaper to administer. Writing a scope document for a ten minute fix costs more than the fix.
Why does a fixed price need a written plan?
A fixed price needs a written plan because the price is only as fixed as the scope it refers to. Without a document saying what is included and what is not, every disagreement becomes a matter of memory, and each side remembers the version that favors it.
Our plans are short: what we would build, what we would leave out, what it costs, and how long it takes. The "leave out" list does as much work as the "build" list. It is where the arguments get settled before they start.
If you are preparing to ask for a fixed quote, our guide to writing a software project brief covers what to put in it. And because a fixed price has to say what happens when you want something new, read how to prevent scope creep as well.
What if the project is too uncertain to price?
When a project is too uncertain to price as a whole, split it into phases. Price the first phase as a fixed piece of work, use what it teaches you to scope the second, and repeat. The uncertain project becomes a series of small certain ones.
Some software is hard to pin down from the outside. The AZLG Case Hub combines intake, a client portal, document generation, e-signature, and a tool that reads medical records and drafts a chronology. A system with that many moving parts is a natural candidate for phases, because how people use the first part informs what the next part should be.
A paid first phase that produces only a plan is also legitimate. We describe that in what a discovery phase is.
How do you choose between them?
Choose by asking whether the work can be written down. If it can, ask for a fixed price and a written scope. If it cannot, pay hourly with a cap or a regular report, or pay for a small fixed first phase that makes the rest definable.
- Write down what you want built. If the list is stable after a week of thinking, the work is definable.
- Ask what is excluded. A fixed quote without exclusions is not really fixed.
- Ask how changes are handled. There should be a clear answer in either model.
- For hourly work, agree a reporting rhythm. Weekly hours and what they produced is enough.
- Ask who pays if it runs over. The answer tells you which model you are really in.
Frequently asked questions
Is fixed price always more expensive than hourly?
Not always. A fixed price includes some allowance for risk, so on a project that goes smoothly you may pay a little more than the hours alone would have cost. On a project that runs over, you pay less. You are buying certainty.
What is a retainer?
A retainer is a recurring payment for an agreed amount of ongoing availability or work each month. It suits maintenance and small improvements after launch, where requests are steady and each one is too small to scope separately.
What is a change order?
A change order is a short written addition to a fixed price agreement. It describes the new work and its effect on cost and timeline, and both sides accept it before the work begins. It keeps changes visible.
Can a project mix both models?
Yes, and many do. A common arrangement is a fixed price for the defined build, then hourly or retainer billing for maintenance and small requests after launch. The two models suit different kinds of work.
Should the cheapest quote win?
Compare what each quote includes before comparing totals. A lower number with a vaguer scope is a different offer, and the difference tends to surface later.
If you can describe what you need, we can tell you whether it is definable enough to price. Send us the problem and we will reply with a written plan.