billable.devPaid Discovery: How Developers Charge for Scoping
By Mark Fulton · 2026-09-03 · 13 min read
Paid discovery is a short, separately invoiced mini-project you sell before the build. You charge a fixed fee, usually a week of work if you are a solo developer, and you deliver three documents: a written specification, a phased estimate, and a ranked risk list. The client buys artifacts they can keep, act on, and even take to a different developer. You get paid for the scoping work you were doing for free, and you get to price the build from evidence instead of a guess. The standard close is that the discovery fee credits in full against the build if the client signs within a set window, which makes saying yes cheap for them and still pays you if they walk away.
Most writing about paid discovery assumes an agency: a strategist, a designer, a project manager, a four week engagement, a five figure fee. That is a different business from yours if you are one developer with a laptop and a client who wants a rebuild quoted by Friday. What follows is the agency-of-one version. One week, three deliverables, one invoice, and a clause that turns the invoice into a deposit if the project goes ahead.
The example running through this post is fictional and used purely for illustration: a small retailer, call them Harbourlight, wants an aging Rails store replatformed. The figures are made up to show the mechanics, not to tell you what your market pays.
Why do free estimates lose developers money?
Because free scoping is not free to produce. It is billable work you decided not to bill.
Count what a real estimate costs you. Reading an unfamiliar codebase well enough to know what is load bearing takes hours, not minutes. Getting the actual requirements out of a client means at least two calls, because the first call produces the version they think they want and the second produces the version their operations lead insists on. Then you write the thing up, break it into phases, and put numbers against each phase. Six hours is a conservative figure for a mid-sized project, and a serious replatform can eat two days.
Now do that three times a month for prospects, and win one. You have spent roughly eighteen hours to get paid for six of them. That is not a marketing cost you absorbed. It is a third of a working week, every month, that came out of your delivery capacity and therefore out of your rate. If you have ever run the arithmetic in how to set your freelance developer hourly rate, unbillable hours are the input that quietly sets everything else.
The second cost is worse, and it is the one that ends projects badly. An estimate written from a forty five minute call is a guess with a confidence interval you are not allowed to show the client. So you do one of two things. You pad it, and lose the job to someone who padded less. Or you do not pad it, win the job, and discover in week three that the payments integration talks to a legacy endpoint nobody mentioned. Then you are having a change order conversation about work you already agreed to do, which is the hardest version of that conversation. The mechanics of digging out are in scope creep and change orders, but the cheaper move is to not be there.
The third cost is positioning. When the thinking is free and only the typing is billed, you have told the client that your judgment is a sales expense and your keystrokes are the product. Every pricing problem downstream traces back to that sentence.
What does a paid discovery actually deliver?
Three documents, named in the agreement, delivered on a date. If you cannot name them, you are selling meetings, and nobody wants to buy meetings.
1. The technical specification. What is being built, in enough detail that someone else could bid it. Current state of the system, the data model as it actually exists rather than as documented, the integration map with each third party service named and its auth method noted, the scope broken into numbered deliverables, and acceptance criteria for each one. This is the document that becomes the deliverables section of the build contract later, which is why it is worth writing properly. The structure it should feed into is covered in the statement of work guide for freelance developers.
2. The estimate. Phased, with ranges, not a single number. Phase 1 catalog and checkout, 90 to 110 hours. Phase 2 admin and fulfillment, 60 to 80 hours. Each phase priced at your rate, with the assumptions that hold the range together written next to it. A range with stated assumptions is more credible than a precise number with none, and it survives contact with reality.
3. The risk register. Ranked, honest, and short. Five to ten items, each with a likelihood, an impact on the schedule, and what you would do about it. "Payment provider migration requires PCI scope review, may add two weeks, mitigate by keeping the existing provider in phase 1." Clients almost never get this from a vendor, and it is the deliverable that most often gets the discovery paid for on the spot.
This structure is not something freelancers invented to sell more. Discovery is a named, funded phase in serious delivery practice. The UK government's service manual on how the discovery phase works describes it as understanding the problem and the constraints before committing to build, and it states plainly that "around 4 to 8 weeks is typical" at government scale. The US Digital Service's discovery sprint guide runs the compressed version, noting that "almost all of the work is completed in 2-4 weeks", with a written report as the output. Your one week solo version is the same idea scaled to one person and one client. When a client pushes back on the concept, those two references are useful: this is how public sector teams de-risk work, not a billing trick.
How much should discovery cost?
The advice you will usually hear is 5 to 10 percent of the project value. That heuristic has an obvious problem for a solo developer: you do not yet know the project value. Knowing it is the deliverable. Pricing a week of work as a percentage of a number you are about to invent is a circular exercise, and it also drags your discovery fee down on exactly the small messy projects where discovery pays for itself fastest.
Price it as what it is. A fixed fee for a defined block of your time producing three named artifacts. Take the number of days you genuinely need, multiply by your day rate, round to something clean, and quote it fixed. For most solo replatform or rebuild work that lands somewhere between two days and one week of effort. If a project is small enough that a week of discovery looks absurd next to the build, run a half day version and charge for a half day. The floor is that discovery should never be free, not that it must be expensive.
Then invoice it separately, before you start, as its own project with its own number. Not a line on the build invoice you hope to send later. Its own document.
The discovery invoice, line by line
Here is the Harbourlight discovery invoice. The $4,600 total and the amounts behind it are illustrative, chosen to show the shape of the document. They are not a benchmark, a market rate, or a claim about what discovery sells for where you are.
| # | Description | Qty | Rate | Amount |
|---|---|---|---|---|
| 1 | Discovery 1 of 3: systems audit and stakeholder interviews. Review of current Rails application and data model, hosting and dependency inventory, 5 stakeholder interviews (ops, finance, marketing) | 1 | $1,750 | $1,750 |
| 2 | Discovery 2 of 3: technical specification. Numbered scope with acceptance criteria, target architecture, integration map (payments, shipping, ERP), explicit out-of-scope list | 1 | $2,000 | $2,000 |
| 3 | Discovery 3 of 3: build estimate and risk register. Phased estimate with ranges and stated assumptions, ranked risk list with mitigations, proposed delivery schedule | 1 | $850 | $850 |
| Total | $4,600 |
Three notes on the notes field, which is doing as much work as the line items:
Fixed fee. Due on receipt. Deliverables issued on cleared payment, on or before 12 September 2026. This fee is credited in full against Phase 1 of the build if a build SOW is executed within 30 days of delivery.
Due on receipt, because there is no reason to extend terms on a two week engagement. Deliverables on cleared payment, because a specification is easy to receive and then stop replying to. And the credit line, because it converts the fee from a cost into a deposit in the client's head, which is the entire pitch.
Notice that the line items describe artifacts, not activity. "5 stakeholder interviews" is checkable. "Discovery work" is not. That distinction is the same one that makes build invoices get paid without questions, which is the subject of what belongs on a software development invoice.
How do you pitch it without scaring the client?
Do not introduce it as a phase. Introduce it as a deliverable with a price and a date, in the same breath as the thing they asked for.
The moment to say it is when they ask what the rebuild will cost. Something close to this, adapted to how you actually talk:
I can give you a number today, but it would be a wide one, because I have not seen the fulfilment integration and that is usually where the surprises live. What I would rather do is a one week discovery. You get a written spec, a phased estimate with real ranges, and a risk list, for a fixed $4,600. Those are yours to keep either way, including if you take them to another developer. If we go ahead on the build, the $4,600 comes straight off the first phase.
Four things are doing the work in that paragraph. You gave a reason grounded in their system, not in your process. You named the artifacts. You gave a fixed price so there is nothing open ended to fear. And you handed them an exit, which is what actually removes the pressure. A client who is told they can walk with the documents will almost never walk.
If it helps, frame the size of the ask against the build. Four thousand six hundred dollars is a real decision. Four thousand six hundred as the first slice of a sixty thousand dollar build, refundable into the build, is a smaller decision than the deposit they were going to have to pay anyway. That comparison is worth making out loud, and it is the same logic behind how much deposit to ask for on freelance web development.
One thing to avoid: do not offer discovery as an alternative to a free estimate you are still willing to give. If free is on the table, free wins. Discovery is how you scope now. That is the whole policy.
Does discovery credit toward the build?
Usually yes, and the credit is what closes it, but write the conditions down or it will be argued about later.
Three decisions to make before you send anything:
Full or partial. Full credit is cleaner to explain and converts better. Partial (say half) protects you if you get a lot of discovery clients who take the documents and shop them. Start with full, and only move if you see the pattern in your own numbers rather than because someone warned you about it.
The window. Thirty days after delivery is a reasonable default. Without a window, a client can come back eleven months later expecting a credit against a build you would now price differently. Anchor it to delivery, not to signature.
What it credits against. Say "Phase 1 of the build" or "the first build invoice", not "the project", so you are not still carrying the credit forward when the engagement runs long.
The clause itself can be one sentence in the discovery agreement:
If Client executes a Statement of Work for the build described in the Discovery deliverables within 30 days of delivery, the Discovery Fee shall be credited in full against the first invoice issued under that Statement of Work. The credit is not refundable, transferable, or redeemable for cash.
That last sentence matters more than it looks. It stops the credit being treated as a general account balance, and it keeps the fee earned rather than held.
Frequently asked questions
What if the client refuses to pay for discovery?
Then you have learned something for the price of one call rather than one week. Clients who will not fund the scoping for a serious build usually also negotiate the build, dispute change orders, and pay late. That said, refusal often means the ask landed wrong rather than that the client is a problem. Try a smaller version first: a half day paid audit with a two page write up, at a price low enough to be a rounding error for them. Plenty of full discoveries start as an audit that impressed someone. What you should not do is fall back to producing the same documents unpaid, because that teaches the next client that the price was optional.
How long should discovery take?
For one developer and one client, two days to two weeks, and you should name the end date in the agreement. Government scale gives you the upper bound and the reason it exists: the UK service manual describes 4 to 8 weeks as typical, and USDS compresses that to 2 to 4 weeks for a focused sprint, both with multi person teams and much larger systems. Scale that down honestly. Discovery expands to fill whatever time it is given, so a fixed end date protects your margin as much as it reassures the client.
Does the client own the spec if they walk?
Whatever your agreement says, so say something. Under US copyright law the default cuts the other way from what most clients assume: a work created by an independent contractor is owned by the contractor unless there is a written agreement, and the Copyright Office's circular on works made for hire sets out that a commissioned work only qualifies as work made for hire when it falls within specific statutory categories and both parties sign an express written agreement saying so. In practice, the commercially sensible position is to grant the client a full license to use the discovery deliverables for their own purposes, including taking them to another developer, while you keep the underlying templates and methods. That is what makes the pitch above honest, and it costs you nothing you were going to sell twice anyway. This is general information, not legal advice, and ownership rules differ outside the US.
Fixed fee or hourly for discovery?
Fixed fee, in almost every case. The point of discovery is to remove uncertainty for the client, and an hourly discovery hands the uncertainty straight back. It also creates the wrong incentive on both sides: they watch the clock, you feel bad about the third interview, and the deliverable gets thinner. Scope discovery tightly enough that you can price it fixed, and put the boundary in writing (five interviews, not "interviews"). The general comparison between the two models is in hourly vs fixed-price billing for developers, but discovery is the one place where the answer is close to universal.
Invoice the discovery phase separately
The habit that makes all of this stick is treating discovery as its own project in your own records. Its own invoice number, its own due date, its own paid stamp. When it is a line item on a build invoice you have not sent yet, it stays hypothetical, and hypothetical work is work you end up doing for free.
Generate this invoice free. Billable runs entirely in your browser, there is no account and no server, and the client's details never leave your machine. Build the three line items above, set the terms to due on receipt, and paste the credit clause into the notes field so it travels with the document. If you would rather start from a filled in layout, the free invoice template for developers is already laid out for this kind of line-item billing, and when the build starts the git log import will turn your commits into the progress invoices that follow. Pro is $4 a month billed as $24 every 6 months, or $79 once, if you want saved client defaults so the second discovery invoice takes a minute instead of ten.