Clients often read a scope of work and assume it's there to protect the developer. It limits what they build, defines when they're "done," and gives them a reason to charge extra if you ask for more. That framing isn't wrong — but it's incomplete.

A well-written scope of work protects both parties. And the party it protects most is often the client.

What an SOW actually covers

A scope of work is a document that defines the agreement before work begins. At minimum it should cover:

What's being built. Not a vague description, but a specific list of pages, features, and deliverables. "A website" is not a scope. "A five-page website with homepage, about, services, team, and contact, including a form that submits via email" is a scope.

What's not included. This is the underappreciated half. Explicitly listing what's out of scope — a blog, e-commerce functionality, a client portal, SEO optimization — prevents the project from expanding through assumption. If it's not listed, the client may assume it's included. If it's not in the document, there's no shared reference when the question comes up.

Timeline and milestones. When does each phase deliver? When is feedback due? What triggers the next milestone? Without this, timeline drift happens exactly the way it always does — gradually, with no clear accountability on either side.

Payment terms. How much, when, and tied to what milestones. Also: what happens if payment is late, or if the project goes on hold.

Revision policy. How many rounds of revisions are included? What counts as a revision versus a new request? This is where most scope disputes actually originate — not in big feature additions, but in "can you just change this a few more times?"

Ownership and handoff. Who owns the code, the design, the accounts? What gets handed over at the end, and in what format?

What happens without one

Projects without a scope of work don't always fail. But when they go wrong, they go wrong in predictable ways.

The developer builds something slightly different from what the client imagined, because the imagined version was never written down. The client asks for changes the developer considers new work. The developer adds time to the project without communicating it. The client is surprised by the invoice. Both feel like the other person changed the deal.

None of this is usually bad faith. It's just what happens when two people hold slightly different mental models of the same project and nobody writes them down to compare.

The questions to insist on before you sign

Before agreeing to work with anyone, get answers to these in writing:

  • What exactly is included in this engagement?
  • What would cause the price to increase?
  • How are changes to scope handled, and what's the process?
  • What constitutes completion of each milestone?
  • What do you need from me, and by when?

If a developer is reluctant to put this in writing, that's information. Good developers expect these questions and usually have the answers ready. Vague agreements are comfortable in the short term and expensive later.

The SOW as a working document

A scope of work isn't just a contract artifact — it's a reference you both use throughout the project. When a question comes up ("did we include that?"), the answer should be in the document. When someone wants to add something, the process should be in the document.

This doesn't have to be a 40-page legal brief. For a small business website, a two-to-three page document covering the items above is often enough. The goal is shared understanding, not exhaustive coverage of every edge case.

If you want something, get it in the scope. If it's not in the scope, assume it's not in the project. That's the right mental model — and it protects you as much as it protects the person building it.