The Spirit of the Scope

Every software project has a scope document. It defines what's in and what's out. It protects both sides: the client knows what they're paying for, the developer knows what they're building.

The problem is that no scope document, no matter how thorough, can forecast everything that a project will need.

Death by change request

You're 3 weeks into a build. The app is taking shape. And someone on the client's side says: "Wait, shouldn't users get an email when their order ships?"

Everyone in the room knows the answer is yes. Obviously yes. Of course the user should get a shipping notification.

But it wasn't in the scope.

In traditional development, what happens next is one of the ugliest rituals in the industry. The agency writes up a change request. They estimate the work at 8 to 12 hours. They send a quote for $2,000 to $5,000. For a shipping email.

The client signs it, because what choice do they have? The app is half built. They're not going to walk away over a shipping notification. But something breaks in the relationship at that moment. A small, quiet fracture. The client starts wondering what else is going to cost extra. They start feeling nickel-and-dimed. Trust erodes.

Do this 3 or 4 times across a project and the client ends up paying 30% to 50% more than the original quote, mostly for things that everyone agrees should have been there from the start.

Scope is a prediction. Predictions are wrong.

A scope document is a best guess at what the finished product needs. Written weeks or months before the thing exists. Before anyone has clicked through it, before real users have touched it, before the dozen small realisations that only happen once you're building.

Some things will always get missed. A filter that obviously needs to be sortable. A dashboard that clearly needs an export button. An admin screen that should let you bulk-edit instead of updating records one at a time.

These aren't feature creep. They're not scope expansion. They're the things that any competent person would look at and say "yeah, that has to be there." They were always part of the product; they just weren't part of the document.

How we handle it

At Launch Assembly, we work by a principle we call the spirit of the scope.

If something wasn't explicitly listed in the original scope, but it clearly should be part of the product, and both sides agree it's obvious, we just do it. No change request. No quote. No meeting about the meeting to discuss the estimate.

We can do this because of how we build. When a senior engineer is working with AI coding tools and deeply understands the system architecture, adding a shipping notification isn't 8 to 12 hours of work. It's a few thoughtful prompts. Maybe 20 minutes. Maybe 45.

The economics of nickel-and-diming clients for these additions simply don't make sense when the cost of doing the work is near zero.

Why other agencies can't do this

Traditional agencies charge for these additions because they genuinely are expensive to build by hand. That shipping email really does take 8 to 12 hours when someone is hand-coding the email service integration, writing the templates, building the trigger logic, writing tests, and deploying it all manually.

So the change request isn't dishonest, exactly. It reflects real cost. But it creates a relationship dynamic where the client is punished for things nobody could have predicted. Where every "oh, obviously it should do that" moment comes with a bill attached.

The client starts self-censoring. They stop raising things that should be fixed because they don't want another invoice. The product gets worse because people are afraid to speak up. The whole thing calcifies around whatever was written in a Google Doc 3 months ago, regardless of whether it still makes sense.

The line still exists

We're not saying scope doesn't matter. It does. There's a clear difference between "users should get a shipping email" (spirit of the scope) and "actually, we also want a full analytics dashboard with custom reporting" (that's a new feature).

The spirit of the scope covers the obvious stuff. The things where, if you showed the product to 10 reasonable people, all 10 would say "shouldn't it do this?" If you have to debate whether it's obvious, it probably isn't.

Real scope changes, genuine new features, meaningful additions that weren't part of the original vision: those still get scoped and quoted properly. That's fair and right.

But the small, obvious things? The ones that make the difference between a product that feels finished and one that feels like a checklist someone stopped halfway through? Those are included. Because they should be.

What this actually means for clients

It means you can relax. You can look at your product as it takes shape and say "oh, it should also do this" without bracing for an invoice. It means the relationship stays collaborative instead of adversarial. It means the finished product is the one that makes sense, not just the one that was described in a document before anyone really understood what they were building.

Every good product is shaped by the dozens of small realisations that happen during the build. The spirit of the scope means those realisations make the product better instead of making the budget bigger.