In short
- Write down what is excluded, not just what is included.
- Name who supplies each input and when.
- Define done per piece, in terms both sides could check.
- Agree how changes are handled before you need the answer.
Scope disputes almost never start with somebody behaving badly. They start with two people holding reasonable but different pictures of the same sentence. "Build the checkout" includes tax rules to one of them and not the other, and nobody finds out until the invoice.
Start from outcomes, not tasks
A task list describes activity. An outcome describes a state you could verify. Outcomes are what you should be paying against, because you can tell whether one has been reached.
| Task framing | Outcome framing |
|---|---|
| Work on the checkout | A customer can buy one item with a card and receive a receipt |
| Improve SEO | Every product page has a unique title and description, and the sitemap lists live products only |
| Design the app | Screens for signup, empty state and the main list, in Figma, in light and dark |
| Write content | Twelve product descriptions of 120 to 180 words, in the brand voice, with meta descriptions |
Write down what is excluded
This is the highest-value paragraph in any brief and the one most often skipped. Exclusions are not hostile; they make the price mean something.
- Content and images, unless somebody is being paid to produce them.
- Third-party accounts, licences and plugin costs.
- Data migration from the old system.
- Training, documentation and handover, if you want them, say so.
- Ongoing maintenance after launch.
- Anything only reachable through an account nobody has found yet.
Name who supplies what, and when
Most projects stall on the client side. Logos arrive late, copy is never written, access takes two weeks to approve. Put the inputs in the scope with an owner and a date, and the schedule becomes something both sides can be held to.
- Designs, and whether they are final.
- Copy, images and any legal text.
- Access: repository, hosting, CMS, analytics, payment provider.
- Test data or a staging environment.
- The person who approves, and their availability.
Define done, per piece
"Done" should be checkable by someone who was not in the conversation. Include the boring criteria, because those are the ones that get argued about: which browsers, which screen sizes, what happens on failure, how many revisions are included.
Weak
The site should work on mobile.
Better
Pages render correctly at 375px and above, in current Chrome and Safari, with no horizontal scrolling and tap targets that work on a phone.
The first is a preference and the second is a test. If a reviewer can check it without a debate, it belongs in the scope; if they cannot, it will become an opinion at exactly the moment the money is due.
Agree the change process in advance
Changes are not a failure of scoping; they are what happens when a plan meets real work. The damage comes from handling them informally, one message at a time, until the freelancer is doing a second project for free or the client is billed for things they assumed were included.
Size the unknowns before you price them
If part of the project cannot be described, do not guess it into a fixed price. Run that part hourly or as a short paid investigation, then scope the rest once the answer exists. Fixed-price versus hourly covers when each is appropriate.
Scope check before you post
- Every deliverable is written as a state, not an activity.
- Exclusions are listed.
- Inputs have an owner and a date.
- Done is defined per deliverable, in checkable terms.
- Revisions per stage are stated.
- The change process is written down.
- The unknown parts are separated from the known ones.
With that in hand, writing the job post is mostly transcription, and the quotes you get back will be comparable.
How detailed should scope be?
Detailed enough that a stranger could quote it and a reviewer could check it. Past that, extra detail mostly constrains how the work gets done, which is the part you hired someone else to decide.
What if I do not know enough to scope it?
Then buy the knowledge first. A short paid discovery, run hourly, is cheaper than a fixed price built on a guess, and it usually pays for itself by removing the padding from the main quote.
Who should write the scope?
You write the outcomes and constraints; the freelancer writes how it will be done. A scope written entirely by the client tends to specify the wrong things, and one written entirely by the freelancer tends to leave out what you actually cared about.