Why I always start with scoping

Most projects that go off the rails don't do so because of code. They go off the rails because no one agreed on what was actually being built.

Before any mockup, I write a scoping document: concrete goals, target audience, technical constraints, editorial tone, and above all what is out of scope. That last point prevents half of all misunderstandings.

In practice, this document is two or three pages. It lists the pages to produce, the expected features, the content the client provides, the content I produce, and a realistic timeline with its validation milestones.

An example: on a showcase site, 'a contact form' can mean three fields and an email, or a booking system connected to a calendar. Between the two lie days of work. Scoping turns that ambiguity into a precise, costed line item.

This document isn't administrative red tape. It's a contract of trust: it states what you'll receive, by when, and at what price. Once approved, we move forward without constantly renegotiating.

It protects both sides. The client knows exactly what they're paying for; I know exactly what I owe. Any out-of-scope request becomes a healthy conversation rather than a source of friction.

The result: fewer surprises at delivery, faster iterations, and a client who always knows where their project stands.