How we scope a project in one week.

Scoping is the part of a project that looks least like work. Nothing is built, nothing is designed, and at the end there is one page of text. It is also where most of a project's cost is decided, because every later decision inherits the answers given here.

This article is about what happens inside that week: the questions we ask and why, the mistakes we see most often in briefs, what a client can prepare, and what the written result should look like.

A brief describes a solution

Most projects arrive as a brief: a list of pages, features or screens. It is a useful starting point, but it describes the solution someone has already imagined. It rarely describes how the work happens today, who does it, or what goes wrong along the way.

Those are the things that decide what to build. So we don't quote from the brief. We use it to decide which questions to ask first.

The questions, and why we ask them

We ask the same questions on every project, in writing, so the answers are on record and nobody has to remember a call:

Users          Who signs in? With what roles? On which devices?
Today          How is this done now, and where does it go wrong?
Never breaks   Which failure would cost money, data or trust?
Languages      Which languages, and who writes the translations?
Data           What exists already? Who owns it? What must be imported?
Integrations   Payments, email, calendars, accounting: which, and why?
Done           What must be true on launch day to call it a success?

Each one is there because its answer changes the project.

Users. "Users" is not an answer. A mechanic confirming bookings between jobs, on a phone with greasy hands, needs a different screen from an owner reviewing the week on a laptop. Roles decide permissions, devices decide layouts, and both are expensive to discover late.

Today. Every new system replaces something, even if it is a notebook or a WhatsApp group. The failures of the old way are the requirements of the new one. The most useful person to ask is whoever handles the exceptions today: the one who fixes the double booking or calls back the customer whose request went missing. They know exactly where the current process breaks.

Never breaks. This question matters most and gets asked least. It separates the details you can change next week from the guarantees you can't. A wrong colour is a small fix. A lost booking or a double charge is a trust problem. The answers get tests first and the most careful review.

Languages. "Albanian and Macedonian" changes the data model, the fonts and the layout, not just the copy. And "who writes the translations?" is often answered with silence, which is worth knowing before the build rather than at launch.

Data. Almost every business already has data: a spreadsheet of customers, an old system, a folder of PDFs. Importing it is often one of the largest items in the scope, and it is almost never in the brief.

Integrations. We ask "why" for each one. An integration someone needs on launch day is scope. One that might be useful one day is a clean place left for later.

Done. A shared definition of success stops a project from drifting. "Customers can book a service from their phone and get a confirmation" is testable. "A modern booking experience" is not.

The failures of the old way are the requirements of the new one.

Mistakes we see in briefs

Most briefs are written with care. They still tend to fall into the same few traps, and each one costs time if nobody notices it.

• Screens instead of work. "A dashboard with charts" says what it looks like, not which decision it helps someone make. We ask what the person looking at it will do next.
• Everything is a must-have. A list of twenty features with no order can't be scoped honestly. We ask which single journey has to work on day one.
• Only the happy path. Cancellations, refunds, no-shows and wrong entries are where most of the real work is. A brief that leaves them out underestimates the project.
• Users without names. "Admins" and "customers" hide very different people. We ask for the actual roles, and how many of each.
• Forgotten data. The spreadsheet that runs the business today is rarely mentioned, and it is often the hardest part to move.
• Integrations as wishes. "Connect it to everything" usually means two systems someone needs, and five that nobody will use.
• A copied competitor. Another company's product solves another company's problem. We ask which part of it the client's customers actually need.
• A hidden budget or deadline. Both are constraints, not secrets. Without them we can't say which version of the project fits.

None of these is a failure on the client's part. Writing a specification is our job. But knowing the traps helps a client see why the questions above matter.

How to prepare

About an hour of preparation makes scoping noticeably faster:

1. Name the people we should speak to, including whoever handles the exceptions, and check they have time that week.
2. Collect real examples of the current process: the spreadsheet, the forms, a few real emails or messages with personal details removed.
3. List what already exists: domains, hosting, accounts, data, and any previous attempts.
4. Write one sentence describing what success looks like six months after launch.
5. Say the constraints out loud: a budget range, a date that can't move, a system that must stay.

That's all. A specification is not needed. Examples of the work as it really happens are worth more than any document.

What a good architecture note looks like

The answers end up on a single page: the architecture note. It is short on purpose. A forty-page specification is written once and never read again; one page gets read by the client, the developers and whoever maintains the system later.

Here is a filled-in example for an imaginary project, simplified. It is illustrative, not a client's document:

ARCHITECTURE NOTE · Online booking for a car service workshop     v1

Users           Customers on phones, often at the roadside, in Albanian.
                Two mechanics who confirm bookings between jobs.
                The owner, who reviews the week ahead every Monday.
Core journey    Customer picks a service, a day and a time → the request
                is saved → a mechanic confirms or offers another time →
                the customer gets the answer by message.
Never breaks    A submitted request is never lost, even with nobody at
                the desk. One slot is never given to two customers.
Data            Services, opening hours, bookings, customers (name and
                phone only). The workshop owns all of it; CSV export.
Boundaries      In: booking requests, confirmation, a list for staff.
                Out: payments, stock, invoices. Phone and WhatsApp stay.
Open questions  Reminders the day before? Decide after a month of use.

What makes it good is not the format. It is the decisions the format forces.

"Never breaks" is testable. "A submitted request is never lost" means the form needs server-side storage and a confirmation, not just an email that might bounce. "One slot is never given to two customers" means a rule in the database, not a check on the page. A weak note says "the system must be reliable", which nobody can test.

"Out" is written down. Payments, stock and invoices are named as out of scope, so nobody discovers in the middle of the build that they were assumed.

Open questions have a date. "Decide after a month of use" turns a disagreement that would have happened during the build into a decision with a time attached.

It names real people. "Two mechanics, between jobs" tells a designer more than any list of personas.

The note is a living document. It is updated when a decision changes, and its final version describes what was actually built, which makes it the first thing the next developer reads.

Related: see where scoping fits in a project, and what it costs →