When a Client Asks for an Hourly Breakdown on a Fixed-Price Project
- A client asking for an hourly breakdown on a fixed-price project usually wants one of three things: proof they got value, something to show their boss or accountant, or leverage for a lower price. Find out which before you answer.
- Use the Profit Room's Outcome Ledger: instead of hours, give a clear breakdown of what was delivered, what each piece does for the business, and how it maps to the price you both agreed. That answers the real question without turning your fixed price into an hourly rate.
- Do not invent hours you did not track, and do not apologize for working fast. If the client genuinely needs hourly billing, that is a different contract for future work, priced accordingly.
The Short Answer
When a client asks for an hourly breakdown on a fixed-price project, answer the need behind the question, not the literal request. Ask what the breakdown is for. Then send a breakdown of deliverables: each piece of the build, what it does, and how it ties back to the agreed price. Do not reconstruct a timesheet you never agreed to keep, and do not convert your price into an hourly rate after the fact. A fixed price is a price for a result, and the breakdown should describe the result.
That is the Outcome Ledger. It works because an hourly breakdown on a fixed-price job sets a trap for both sides. If you show few hours, the client feels overcharged, even though they agreed the price was worth it. If you pad the hours, you are being dishonest. Building with Claude Code makes this sharper, because good work can take far less time than the client imagines. The fix is to keep the conversation on what they got, which is where [value-based pricing](/blog/value-based-pricing-stop-charging-hourly) put it in the first place.
Why Clients Ask for an Hourly Breakdown
The request sounds the same every time, but the reason behind it is not. Ask one question first: 'Happy to help, what will you use the breakdown for?' The answer is almost always one of these.
- Internal paperwork. Their finance team, accountant, or a grant or budget process wants costs split into categories. They need structure, not hours. The Outcome Ledger solves this cleanly.
- Reassurance. The project felt quick, and they want to know they got their money's worth. They need to see the value, not the clock.
- Price pressure. They suspect the build was easy and want a number to argue down. This is really a discount request, and [when a client asks for a discount](/blog/client-asks-for-a-discount) covers how to handle it.
- A second opinion. Someone else, often another developer, told them the work 'should only take a few hours.' Treat it the way you would [a client who hires a developer to review your code](/blog/client-hires-a-developer-to-review-your-code): calmly, with the scope in front of you.
If the request arrives alongside a refusal to pay, it is no longer a breakdown question. It is an invoice dispute, and [when a client disputes an invoice](/blog/client-disputes-an-invoice) is the playbook to use.
Build the Outcome Ledger
The Outcome Ledger is a one-page breakdown of the project by deliverable, not by time. Work through it in order.
- List every deliverable in the signed scope. Use the same names as your [scope of work](/blog/scope-of-work-that-prevents-scope-creep) so the client can check each line against what they agreed to.
- Add what each piece does for the business. One plain sentence: 'Sends a reminder before every booking so fewer appointments go empty.' This is the line that answers 'was it worth it?'
- Include the work they did not see. Discovery calls, testing, fixing edge cases, setting up accounts, writing handover notes, and your post-launch support window are real parts of the job. Name them as deliverables.
- Map the lines to the price. If you billed by milestone, show each milestone and its amount, which is where [structuring client payments in milestones](/blog/structure-client-payments-milestones) pays off. If it was one fixed fee, group the lines under it.
- Note anything added along the way. Extra work that came in through a [change order](/blog/change-order-template-for-a-claude-code-project) gets its own line, so the client sees exactly where every dollar went.
| Question the client has | Hourly breakdown answers with | Outcome Ledger answers with |
|---|---|---|
| What did I pay for? | A list of hours | A list of deliverables they can check against scope |
| Was it worth it? | A rate they can compare to someone cheaper | What each piece does for the business |
| What does my accountant need? | Hours they never asked you to track | Costs grouped by deliverable or milestone |
| Why did it cost this much? | An invitation to argue over time | The agreed price, line by line |
Outcome Ledger versus an hourly breakdown
In the Claude Code desktop app you can ask Claude to read the project and the signed scope and draft a first version of the ledger. Check every line yourself before you send it, because the client will.
What to Say
Notice what the message does. It says yes to helping, so the client does not feel brushed off. It explains, without apology, why there are no hours to share. It offers something more useful than what they asked for, and it invites them to name the format their paperwork needs. It does not make up a number, and it does not defend how long the work took.
If they push for hours anyway, stay calm and hold the line: 'The price was for the finished build, not my time, which is why it stayed fixed even when parts took longer than planned. I would rather show you exactly what you got than give you a number that does not mean much.' Most clients accept this, because a fixed price also protected them from overruns.
When the Client Really Needs Hourly Billing
Some clients genuinely need hours, for example because of how their budget approval works. That is fine, but it applies to future work, not to a project you already priced. Offer a separate arrangement for the next phase, and price it so you are not penalized for working fast. A monthly plan with a set scope often fits better than open hourly billing, and [pricing a Claude Code retainer](/blog/how-to-price-a-claude-code-retainer) covers how to set it up.
To stop this question before it starts, say in your [expectations conversation](/blog/set-client-expectations-before-a-claude-code-build) that the price is for the result, not the hours, and add a line to your contract saying fixed-price work is reported by deliverable. If the client is worried about how AI fits into your speed, [should you tell clients you use AI](/blog/should-you-tell-clients-you-use-ai) covers that conversation. And at your next [quarterly review call](/blog/quarterly-review-call-with-clients), lead with the Outcome Ledger, so the value is in front of them before anyone thinks to ask about time.
Short, practical drops on offers, outreach, pricing, and closing clients with Claude Code. No spam, unsubscribe anytime.
Frequently asked
Do I have to give a client an hourly breakdown on a fixed-price project?
No, unless your contract says so. Offer a breakdown by deliverable instead, showing what was built, what each piece does, and how it maps to the agreed price.
Should I estimate my hours if I did not track them?
No. Made-up hours are not accurate, and they turn a fixed price into an hourly rate the client can argue with. Explain that the price was for the result and share the deliverable breakdown.
What if the client says the work only took a few hours?
Keep the conversation on the result and the signed scope. They agreed to the price for the finished build, and the fixed price also protected them from any overruns.
What should a deliverable breakdown include?
Every item in the signed scope, one sentence on what each does for the business, the behind-the-scenes work like testing and setup, how the lines map to the price or milestones, and any change orders added along the way.
What if the client needs hourly billing for future work?
Offer a separate arrangement for the next phase, such as a monthly plan with a set scope, priced so working fast does not cost you. Do not change the terms of a project that is already priced.
Last reviewed November 13, 2026.
Co-founder of the Claude Code Profit Room. Built and sold AI services to real clients; writes about offers, pricing, outreach, and closing with receipts.
More from Duncan Rogoff →
