Why every project starts with a written scope, and what is in it

Before we build anything, we write down what we are building. It sounds obvious, and it is the step most often skipped, usually because everyone is in a hurry to start. We are not, and here is what the document contains.

What is in the scope: a two-page outline

Page one is the problem. In plain words, what is slow, manual or invisible today, who it affects, and what “better” would look like in a number if there is one. If we cannot describe the problem in a paragraph, we are not ready to price a solution.

Page two is the build. The screens or automations, listed. What each one does, what it connects to, and what it does not do. The accounts the finished system lives in and who owns them. The price. The delivery in slices, so the first useful piece is in use early, not at the end.

An outline of a scope looks like this:

1. The problem. Who does what today, where the time goes, and what goes wrong.
2. What “done” means. The one or two things that will be true when the build is finished.
3. What gets built. Each screen, automation or report, one line each.
4. What it connects to. The tools, accounts and data it reads from or writes to.
5. What is not included. Named, so nobody assumes it.
6. Slices and dates. The order the pieces arrive in, and when.
7. Ownership and accounts. Where the system runs and who owns the code and the data.
8. Price and care. What the build costs, and what ongoing care costs if you want it.

What the scope is not

It is not a specification of every button. Details change once the first slice is in use, and they should. The scope fixes the shape and the price; the detail is worked out together as we go.

It is also not a way to say no to changes. When something new comes up, and it always does, it goes on a short list, and at the end of a slice we decide together whether it replaces something, extends the scope, or waits. Nothing is silently absorbed and nothing is silently dropped.

Scope of work or statement of work

People use both terms. A statement of work is usually the formal contract document that wraps the scope, with terms and payment schedules. The scope is the part that says what will be built. For a small business, the scope is the part worth reading closely.

Why we insist on it

Because you should be able to say yes without a leap of faith. A written scope means you know what you are paying for, when you will see it, and where it will live. And it means we build from a document you agreed, not from a memory of a phone call.

It is how every Alif Logix project starts, and it is the cheapest part of the whole build. Here is how a custom software build runs after the scope is agreed.