Turning a vague client request into an executable scope

23 August 2026Majed Alandajani

Technology is rarely what kills a software project. The usual killer is a verbal agreement: the client and the builder understood two different things, then shook hands on the misunderstanding.

The problem as it actually happens

The client says "I want a site with booking." You build booking. Then it turns out booking meant booking with payment, so you add payment. Then the question about invoices arrives. At every step the client believes they are clarifying the original request, while from where you sit the scope keeps growing.

Nobody is lying. A vague request gets filled in with assumptions on both sides, and the two sets of assumptions never match.

This keeps happening because natural language is ambiguous by default. "A fast site" means, to the client, that it opens instantly on their phone on a weak connection; to you it means an excellent performance score on a fast network. Both readings are honest. A verbal agreement preserves that ambiguity intact until delivery day, which is the most expensive possible moment for it to surface.

The alternative I rejected: the PDF proposal

The standard move is to send a PDF proposal with the scope inside. I dropped it for three reasons I hit in practice.

You never learn whether the file was read; it arrives and silence follows. Approval leaves no trace, because "sounds good" in a chat thread proves nothing once a dispute starts. And copies multiply: edit one clause and you hold two files, with the client's copy making three.

What I do instead

Each client gets a private offer page, on a link that cannot be guessed and is not indexed by search engines. The page walks through the scope item by item, with what falls outside the scope stated explicitly, along with the duration and the milestones.

At the bottom sits an approve button. Clicking it writes the approval into a record that cannot be edited or deleted, stamped with the time and the exact version the client approved.

Why "out of scope" matters more than "in scope"

A list of what you will build does not prevent disputes. The list of what you will not build is the one that prevents them. Mine always carries the same items: migrating old content, brand identity design, writing the copy, maintenance after handover, and training.

Every item earned its place there because a client once requested it while assuming it was already in the price.

The scope structure I write

The goal in one sentence: what changes in the client's business after delivery.
The deliverables by name: a home page, three service pages, a contact form, and an admin panel for the content. The bare word "website" commits nobody to anything.
What is out of scope, for the reasons above. It remains the most important list in the document.
Milestones with acceptance criteria. "60% complete" carries no information; a milestone ends with something the client can see and either accept or reject.
The client's responsibilities: the content, the images, access to accounts, and review within a set period.

A project that slips because the client is late has to visibly show it slipped because of the client, and the record can only show that when their commitments exist in writing.

Pricing: what I learned the hard way

Do not price before knowing the budget. This has nothing to do with tuning your price to the number. The budget exposes the gap between what the client expects and what the work actually requires, and that gap belongs in the first meeting, while it is still cheap. Two weeks into writing a proposal, it is expensive for everyone.

When the scope is clear, I price the scope itself. When it stays fuzzy, I price my time, and I tell the client that in plain words.

Handling additions

An addition after the agreement is a healthy sign; a client who keeps thinking about the project is invested in it.

The trouble starts when the addition gets built for free, because every request after that one arrives carrying the same expectation.

The reply I use: "this is outside what we agreed; here is its cost, and here is what it does to the date."

What this gives you in practice

When a client asks for an addition after signing, nothing rests on memory. You open the same page they approved, dated and versioned, and look at it together. From there the discussion is about pricing new work, and both sides can have that discussion calmly.