One of the durable myths of freelance work is that clients arrive with a clear brief. They sometimes do. More often, they arrive with a problem, a budget that may or may not be appropriate to the problem, and a vague sense that something needs to happen. Turning that into a scoped project is half the job. The other half is doing the work — which is often the easier half.
The difference between a freelancer who is comfortable with this and one who is not shows up in how the early conversations go. The uncomfortable freelancer pushes hard for specification, asks for a written brief, treats the client’s uncertainty as a defect to be corrected. The comfortable freelancer treats the uncertainty as the starting condition, expects to do meaningful work to resolve it, and prices that work into the engagement rather than pretending it does not exist.
The skill of scoping vague projects is one that nobody teaches and most people learn the hard way. Some patterns recur often enough to be worth describing directly.
Why clients are vague (it is usually not laziness)
The first reframe that helps is recognising why clients arrive with unclear briefs. It is rarely because they have not bothered to think about it. It is more often because the problem itself is genuinely unclear, the client’s understanding of what is possible is incomplete, or the political or organisational context is too tangled to summarise in a few paragraphs.
A client commissioning a website rebuild may not know whether the underlying problem is design, content, technology, performance, organisational structure, or some combination. A client commissioning documentation may not know whether the issue is that the documentation does not exist, that it exists but nobody finds it, or that it exists and is correct but no longer matches the software. The client knows there is a problem. They are paying you, in part, to help name it.
Treating that vagueness as the freelancer’s problem rather than the client’s failure is most of the shift in mindset. A clear brief is wonderful when it appears. An unclear one is not a sign that the client is unprofessional; it is a signal that the early phase of the work is about resolving the question, not yet about answering it.
The first conversation is not the brief
The most common mistake in scoping a vague project is to treat the first conversation as if it were the brief. The client says they want a new website, the freelancer asks what they have in mind, the client describes it in general terms, the freelancer produces a proposal. The proposal is wrong, but in ways that nobody can see until much later — usually after work has started and changes are expensive.
The first conversation is for understanding the shape of the problem, not for scoping the solution. The questions that matter at this stage are diagnostic, not specification.
What is happening that prompted you to look for help right now? What have you tried already? What would success look like in six months — described in terms of outcomes for the business, not features of the deliverable? Who else in the organisation cares about this, and what do they care about? What is the budget likely to be, and where is it coming from?
None of those questions are about deliverables. All of them surface the context that makes the eventual deliverable make sense. A freelancer who skips this stage and goes straight to scoping is scoping in a vacuum.
The interim deliverable: a scoping document
For projects that arrive vague enough to need real work to scope, one of the most useful structures is to make the scoping itself a small paid engagement, with its own deliverable. A scoping document, produced in a week or two, that articulates the problem, the options, the recommended approach, and the basis for an accurate quote.
This is sometimes called a discovery phase, an inception, a kick-off engagement, or simply a paid quote. The name matters less than the structure. The freelancer is paid for a small, defined piece of work that produces a deliverable both parties can react to, before any commitment is made to a larger engagement.
This structure solves several problems at once. It compensates the freelancer for the genuine work of resolving the client’s uncertainty. It gives the client a tangible deliverable that has value even if they decide not to proceed. It surfaces disagreements about scope early. It produces the basis for an accurate quote.
The hardest part of this structure is selling it. Clients who are used to free quotes can read a paid scoping engagement as an upsell. The framing that tends to work is honesty: the project as described is too unclear for an accurate quote, a free quote on this much uncertainty would be a guess in both directions, and the small fee for scoping is what makes the larger quote trustworthy. Some clients will not accept this framing. Those are usually the clients who would have produced a bad project anyway.
What to put in the scoping document
The scoping document does not need to be long. Most of the useful ones are between four and twelve pages. The structure is roughly:
Restate the problem. One section that articulates, in the freelancer’s words, what the freelancer understands the client to need. This is the first useful deliverable on its own. Often the client reads it and says “actually, that is not quite what we meant” — which is exactly the kind of clarification you want to surface early.
Describe the current state. What exists today, what is working, what is not, what the constraints are. The act of writing this down often reveals constraints that the client had not consciously articulated.
Outline the options. Two or three approaches to addressing the problem, with the trade-offs of each. Time, cost, risk, fit. The freelancer is not yet committing to one. They are showing the client the choices that are available.
Recommend an approach. The freelancer’s view on which of the options best fits the client’s situation, with reasoning. This is where the freelancer earns their fee — by exercising judgement, not just describing.
Define the scope, deliverables, and price for the recommended approach. This is the proposal element, but it is grounded in everything that came before it. The price is no longer a guess; it is a calculation based on understood requirements.
Note what is out of scope. Equally important. Listing the things that are not included reduces the risk of expectation drift later.
Pricing the scoping itself
The scoping engagement has to be priced low enough that the client can commit to it without significant procurement effort, and high enough that the freelancer is fairly paid for the work involved.
For most projects, this works out to something between a few hundred and a few thousand, depending on the size of the eventual engagement. As a rough rule of thumb, around five to ten per cent of the expected total project value is a reasonable bracket.
It is worth being explicit about what the scoping fee buys: a defined deliverable, a defined turnaround, and a quote for the larger engagement that is firm rather than indicative. The relationship between the scoping fee and the larger project can vary — some freelancers credit the scoping fee against the project if the client proceeds, some do not — but the relationship should be stated up front.
What to do when the client will not pay for scoping
Some clients, particularly smaller ones, will resist a paid scoping engagement. In those cases, the freelancer has a few options. Provide a very short free conversation, but keep it actually short and use it to identify whether a real project exists at all. Quote with explicit assumptions and a generous contingency, and revise the quote if the assumptions turn out to be wrong. Decline the project on the grounds that the uncertainty is too high to scope responsibly.
The third option is underused. There are projects where the right response is to walk away because the client is not ready to commission them, and helping the client see this clearly is more valuable to both sides than agreeing to a project that is going to go wrong.
The short version
Half of good freelance work is helping a client articulate the brief. The clients who arrive with a polished specification are the minority; most arrive with a problem and a hope. Treating that vagueness as the starting condition — and pricing the work of resolving it into the engagement — is more honest and more durable than pretending the brief was clear. A paid scoping engagement, ending in a written document the client can react to, is the structure that tends to work best. It produces accurate quotes, surfaces disagreements early, and protects both sides from the projects that should never have started.
