How to scope a Claude Code project: pin the outcome, then size the rungs
Here is how to scope a Claude Code project without underquoting: pin the outcome the client actually wants, break it into deliverables, mark every unknown before you price it, then size each rung and add a buffer for the parts you cannot see yet. Underquoting almost never comes from bad math. It comes from quoting the thing the client asked for instead of the thing they actually need, and from pricing the parts you understand while waving past the parts you do not.
I have spent fifteen years shipping inside teams at Apple, PlayStation and Schwab, and the projects that lost money were rarely the hard ones. They were the ones that looked simple and hid a swamp underneath. A clear scope is not paperwork. It is the thing that keeps you solvent.
The Scope Ladder: a five-rung method for pricing a build
The Scope Ladder is our CCC method for turning a vague request into a defensible number. Each rung has to hold weight before you climb to the next. You work top down, from outcome to price, so the number rests on the outcome and not on your optimism.
- Pin the outcome the client actually wants. Not the feature they named, the result they are buying. Fewer hours on a task, faster replies to customers, a report that writes itself. Write it as one plain sentence.
- Break it into deliverables. List the concrete artefacts that produce that outcome: the Claude Code agent, the prompt library, the integration, the handover doc. If it is not on the list, it is not in the price.
- Mark the unknowns. Go through every deliverable and flag anything you have not personally done before or cannot confirm without access. An unmarked unknown is where the money leaks.
- Size each rung. Estimate the effort for each deliverable on its own. Small pieces are easier to size honestly than one big lump, and a lump always gets rounded down.
- Add a buffer for the unknowns. The parts you flagged in rung three carry the most risk, so they carry the most padding. This is not a fudge. It is priced risk.
Where scope goes wrong with AI builds specifically
AI builds carry a specific trap. The demo works in ten minutes and the client assumes the whole thing is ten minutes. The last mile, making a Claude Code workflow reliable across real inputs, edge cases, and the client's actual data, is most of the work and none of the wow.
Scope that last mile explicitly. Put reliability, testing against real examples, and handover on the deliverables list as named rungs. If they are invisible, the client will not value them and you will not get paid for them.
The other trap is access. A large share of AI work depends on data and systems you do not control on day one. Treat every dependency you cannot verify as an unknown and price it as risk, not as a rounding error.
Turning the ladder into a number the client will accept
Once the rungs are sized, the number almost writes itself. Present it as a fixed fee tied to the deliverables, not an open hourly count, so the client is buying an outcome and not renting your time. A fixed fee also protects you: if you get faster, you keep the upside.
For a piece where the unknowns are genuinely large, quote a small fixed fee for a short discovery phase first. You learn what you are actually dealing with, and you get paid to reduce your own risk before you commit to the full number. Clients respect this. It reads as competence, not hesitation.
Make it a habit, then compare notes
The Scope Ladder is only useful if you run it every time, including on the small jobs that feel too simple to bother with. Those are the ones that quietly eat weekends. Five rungs, top to bottom, before any number leaves your mouth.
Every agency owner has a story about the project that looked simple and was not. If you are scoping a Claude Code build right now and want a second pair of eyes on your rungs, bring it to the CCC community and compare notes. Someone there has almost certainly priced something close to it.
Frequently asked questions
What is the Scope Ladder?
The Scope Ladder is a CCC method for scoping a Claude Code project in five steps. You pin the outcome, break it into deliverables, mark the unknowns, size each rung, then add a buffer for the unknowns. It builds your price from the outcome up so the number is defensible.
How do I avoid underquoting an AI build?
Underquoting usually comes from pricing the parts you understand and skipping the parts you do not. Mark every unknown before you quote and price it as risk. Scope the reliability and handover work as named deliverables, because that last mile is most of the effort.
Should I charge fixed price or hourly for a Claude Code project?
A fixed fee tied to deliverables is usually stronger. The client buys an outcome instead of renting your time, and you keep the upside if you get faster. Reserve hourly for genuinely open-ended work where the scope cannot be pinned yet.
What if the client's scope is still vague?
Quote a small fixed fee for a short discovery phase first. You get paid to reduce your own risk, learn what you are actually dealing with, and then quote the full build with confidence. It reads as competence, not hesitation.
How big should the buffer for unknowns be?
There is no single number. The buffer should scale with how many unknowns you flagged and how far outside your experience they sit. The point is that the buffer is priced risk on the specific unmarked parts, not a vague pad on the whole job.
Do I really need to scope the small jobs?
Yes. The small jobs that look too simple to formally scope are the ones that quietly run over and eat your margin. Running the ladder takes minutes and it catches the hidden swamp before you commit to a number.
Last reviewed by Duncan Rogoff on June 27, 2026
