Scope creep isn’t one big ask you can say no to. It’s fifteen small “while you’re in there” requests that each sound reasonable alone and add up to a project that’s twice the size you scoped, with no single moment where you could have obviously objected.

Name the baseline in writing, before you start

If the scope was never written down, there’s nothing to creep away from — every addition feels equally legitimate because there’s no line to cross. Before work starts, write the one-paragraph version of what’s in and, just as important, what’s explicitly not:

## In scope
- Users can reset their password via email link
- Link expires after 1 hour

## Explicitly not in scope (this round)
- SSO / social login
- 2FA
- "Remember this device" option

The “explicitly not” section is the part people skip and the part that actually prevents creep. Without it, every new idea gets evaluated against a vague sense of the project instead of against a written line.

The “while you’re in there” tax

This is the most common vector, and it’s insidious because it’s usually framed as efficiency: “since you’re touching the auth code anyway, can you also add 2FA?” The efficiency argument sounds true and is usually wrong — touching related code doesn’t mean the new work is small, it means the new work is now entangled with the old work’s timeline and risk.

Answer with a genuine yes-and, not a no:

Good idea — let’s scope that as its own ticket after this ships. Bundling it in now means the password reset work waits on 2FA design decisions that aren’t made yet.

You’re not blocking the idea. You’re refusing to let an unscoped idea attach itself to a scoped one.

Track additions, don’t just absorb them

Keep a visible running list of everything added after the baseline was set, even the ones you agreed to. This does two things: it makes the cumulative size of “small” additions visible to whoever’s asking for them, and it gives you a concrete artifact when someone asks why the timeline moved.

Added after baseline (2026-07-01):
- Rate limiting on reset endpoint (+1 day) — added 07-03
- Support for expired-link resend (+0.5 day) — added 07-05
- Admin-triggered reset (+2 days) — added 07-08, still pending

A list like this, shown in the next status update, reframes “the project is late” as “the project grew by 3.5 days of newly requested work,” which is a true statement and a very different conversation.

The line that actually works

When a new request comes in mid-project, the useful response isn’t yes or no, it’s a tradeoff:

We can add that. It pushes the ship date by two days, or we cut the resend-email feature to keep the date. Which do you want?

This works because it doesn’t require you to be the bad guy who says no — it hands the tradeoff to the person asking, who almost always has more context on which one actually matters. Most scope creep survives because engineers absorb the cost silently instead of surfacing it as a choice.

What doesn’t work

Refusing every change on principle burns trust and gets you routed around — people stop asking and just tell you it’s already decided. The goal isn’t zero scope change, it’s zero silent scope change. Every addition should cost something visible: a day added, a feature cut, a new ticket. The moment additions are free, you’ll get an unlimited supply of them.