How we scope

Start with your words

Send the brief however it comes out: an email, a voice note transcribed, a slide, a photo of a whiteboard. We will ask questions, usually in one round, sometimes two. The questions are about the job to be done, who does it today, what systems are involved, and what date matters and why.

What a scope contains

A scope is a short document, usually one to two pages:

The problem in one paragraph, in your words, corrected by us only where we misunderstood.
The deliverable as a list of concrete things that will exist: screens, endpoints, jobs, reports, documents.
Done means a checklist you can tick without us in the room. "A customer can log in with their email, see their last twelve invoices and download any of them as PDF."
Not included so nobody is surprised later.
What we need from you and by when.
Dates: kickoff, first test address, delivery.
Price, deposit and payment terms.

Why "done means" matters most

Most disputes in software come from two people picturing different things behind the same words. The done-checklist is where those differences surface early, when they are cheap. We would rather spend a day arguing about the checklist than a month arguing about the result.

Changes

Things change. When they do, we write the change down as its own small scope: what, why, what it costs, how it moves the date. You approve it or not. Nothing is slipped in and nothing is billed that was not agreed. Small changes that cost us nothing are simply done.

Fixed scope versus ongoing

For a clear deliverable, fixed scope is fairer to both sides. For work that evolves, a monthly budget with a reviewed plan is better; the scope then becomes a rolling list, prioritised together each month. Pricing explains both.

What we will not scope

Projects described only as "like X but for us", projects where nobody on the client side can answer questions, and projects where the budget and the deliverable cannot be made to meet. In the last case we say so and suggest the version that fits.