Fixed price vs hourly design: the short answer
Fixed price vs hourly design comes down to who carries the risk of a wrong estimate. For most defined web and product design work, fixed price is the better way to pay. The designer sets a number for a described deliverable. If the estimate is wrong, the designer absorbs the difference, not you. Hourly billing makes sense when the work genuinely cannot be defined yet, because nobody can price something honestly before they understand it. A monthly retainer is a different case again: it pays for ongoing work with no single finish line, not a one time deliverable.
This post is written for the person hiring and paying a designer, not for designers deciding how to charge. Three billing models cover almost every engagement: fixed price, hourly, and retainer. Here is how each one works, and what it does to your risk.
The three ways you can pay a designer
Each model puts a different party on the hook when an estimate turns out to be wrong. Read the table by column, not just by row, and decide which risk you would rather carry.
| Billing model | Best when | Who carries the estimate risk | What you must define before you sign | How it goes wrong for the buyer | |---|---|---|---|---| | Fixed price project | The deliverable is describable | The designer | Scope and the number of revision rounds | Loose scope turns every change into a paid change order | | Hourly | The problem is still undefined | You | A budget ceiling and a reporting cadence | Hours accumulate with no shipped artifact to show for them | | Monthly retainer | The work is continuous, with no single finish line | Shared | What the monthly fee actually buys | You pay for capacity you did not use that month |
Fixed price changes how you behave as a buyer, not just what you sign. You spend more time up front on scope, because that scope is what protects you later. Hourly asks the opposite: less time defining scope, more time watching the clock and the invoice. A retainer asks you to trust a queue, and to check every month that it was actually full.
How a fixed price quote actually gets built
A fair fixed price quote follows a sequence. Skip a step and the number underneath it gets shaky.
It usually starts with a scoping or discovery conversation. From there, the designer writes a list of the actual screens and states involved, not just a page count. Next comes an exclusions list, stating what is not included. Then a stated number of revision rounds. Only after all of that does a number appear.
If a designer quotes you a fixed price without asking what the screens and states are, they are guessing. You pay for that guess later, in change orders that were never priced into the original number.
A fixed quote also usually includes a contingency buffer. The designer is absorbing your estimate risk, and that buffer is how they price it. It is the cost of certainty, and it is a real cost you are choosing to pay.
The details differ by project type. A marketing site is scoped by page and by breakpoint. A design system is scoped by component count and by how much of the token set it covers. A web app is scoped by flow, and by whether empty, loading and error states are included for each one. An MVP is scoped by how many flows have to work end to end, not by how the product will eventually look.
On a recent scoping call for an anonymized composite client, a B2B trading platform, the initial request was simply "redesign the dashboard." That is not a quotable scope. Two calls later it became six named screens, three states each, two revision rounds, with reporting and admin views explicitly excluded. That is quotable.
If you want the same logic applied to a specific engagement type, what a UX audit costs and what changes the number walks through it for audits.
The real math on a scope overrun
These are round hypothetical numbers, used to show how the mechanics work, not market rates. Real numbers vary by scope, market and the designer's experience.
Say a landing page and a small design system get scoped at 40 hours, at an agreed rate we will call R. The designer ends up delivering the work in 52 hours.
| Scenario | What you pay hourly | What you pay fixed price | Who absorbs the difference | |---|---|---|---| | Runs to plan, 40 hours | 40 times R | The quoted figure | Nobody, the estimate was right | | Overruns to 52 hours | 52 times R | The quoted figure | The designer absorbs the extra hours | | Comes in short, 32 hours | 32 times R | The quoted figure | You do not benefit from the hours saved |
On the overrun, the hourly buyer pays for 52 hours. That is well above the budget your approval was based on. The fixed price buyer pays the quoted figure, and the designer eats the difference.
Here is the part most comparisons skip. If the work finishes early, at 32 hours, the hourly buyer pays for 32 hours and saves money. The fixed price buyer still pays the full quote.
Fixed price is insurance. Insurance costs something even in the years nothing goes wrong.
Choose fixed price when a budget overrun would actually hurt you, in approvals, in cash flow, or in trust with your own stakeholders. Choose hourly when you can genuinely absorb the variance either way.
When hourly is the right call for you
Hourly is not a worse model. It is the right one in specific situations, and I will say so even though most of my own work is quoted fixed.
Four situations where hourly genuinely wins for you as the buyer:
- The problem is still being discovered, and no deliverable can be named yet.
- The work is small and open ended, like ad hoc UI fixes on an existing product.
- You need a designer on call for a launch window, where the workload is unpredictable.
- You are trialing a new designer and want a low commitment way to test the fit.
If you go hourly, put safeguards in place. Ask for a written ceiling on hours before work starts. Ask for a weekly report of hours worked. Set a rule that the designer flags you before crossing the ceiling, not after.
A designer who refuses hourly for a genuinely undefined problem is protecting their own margin. They are not protecting your outcome.
If you are unsure whether now is even the right moment to start this conversation, whether it is the right moment to bring a designer in is worth reading first.
When a retainer makes more sense than either
A retainer is a billing structure, not a level of commitment. It pays for continuous access to design capacity, month over month, for work with no single finish line.
Before you sign one, get clear answers on the mechanics:
- What exactly the monthly fee buys, in hours or in a defined output.
- Whether unused capacity rolls over to the next month, or is lost.
- How work gets queued and prioritized within the month.
- The notice period required to pause or end the arrangement.
- Whether the fee is invoiced flat, or reconciled against what was actually delivered.
The test for whether you need one is simple. You have a continuous queue of design work, and pricing every small task as its own fixed quote would cost you more time than it saves.
The failure mode is just as simple. You pay the standing fee in a month where the queue sat empty.
Cadence is a separate question from billing, and it deserves its own answer. How often you actually need a designer covers that side of the decision.
What a fixed price design contract should include
- A written deliverable list, naming the screens, states and breakpoints involved.
- An explicit exclusions list, stating what is not included.
- A stated number of revision rounds, with a clear definition of what counts as one round.
- A change order process, with a defined rate or method for pricing anything added later.
- Payment milestones tied to delivery, not to calendar dates.
- File and source ownership transferring to you on final payment, including Figma files and any code.
- A stated timeline, with the dependency named. Usually that dependency is your own feedback turnaround.
Most fixed price disputes do not come from the price itself. They come from an exclusions list that was too short, or missing entirely.
How to tell if a fixed price quote is fair
Fairness here is not about comparing a number to a market rate you do not have. It is about whether the quote is specific enough to check.
Run a quote through four tests:
- Does it break down by deliverable, or is it a single number with no explanation.
- Does it name what is excluded.
- Does it state the number of revision rounds included.
- Did the designer ask real scoping questions before quoting, or price it from a one line brief.
If you are comparing two quotes, check the scopes match before you compare the totals. A cheaper quote is often just a smaller scope in disguise. Normalize the scope first, or you are simply picking whoever scoped the least work.
I am not going to give you a market rate here, and that is deliberate. Rates vary too widely by market, by seniority and by specialty for a single number to be honest. Anyone who gives you one without asking where you are hiring from is guessing.
If you are sourcing outside the big marketplaces, where to find a designer outside the marketplaces is a good next read.
Where I stand, and the bias you should know about
Most of my own client work is sold fixed price. That gives me a commercial interest in recommending it to you, and you should factor that in as you read this.
The boundary I drew earlier is what makes that disclosure worth something. Hourly is the better buy for you when the problem is genuinely undefined. I said that above, not around it.
If you want to see how a fixed scope actually gets built and delivered, a full walkthrough of the audit process shows the mechanics end to end.
If you are weighing a first fixed price engagement, a UX audit is usually the smallest fixed scope you can start with, before committing to a larger fixed price project.