Sometimes Scope Creep Means the Project Is Working
Halfway through a build, we realised the product needed document uploads. It wasn’t in the scope, nobody had asked for it, and the product wouldn’t really work without it. That’s scope creep — but it’s also part of discovering what the product actually needs.
The example
Partway through the build, it became clear the product needed document upload. It wasn’t in the original scope. Nobody had asked for it, and nobody had ruled it out either.
The client agreed: yes, it’s extra scope, and yes, it has to go in. It filled a gap nobody had specified.
Why nobody caught it earlier
Why wasn’t it in the scope from the start? Because nobody knew it was missing. What I said on the call:
“I don’t know what’s missing. If I knew what was missing, I would help you. We just have to dive in and do it.”— me, on the call
A spec describes the product you can imagine before it exists. Some gaps only show up when you can click through the real thing. That isn’t a failure of planning. It’s the reason you build instead of planning forever.
Two kinds of scope creep
The useful question isn’t “is this new?” It’s “does the product work without it?”
- A gap: the product doesn’t do what it’s meant to do without it. Document upload was this.
- A wish: the product works, and this would make it nicer. That one can wait for the next round.
Gaps go in. Wishes go on the list.
What founders should take from this
- Expect gaps. Nobody can list every missing piece before the build starts, including your developer. Plan your budget and timeline knowing some will turn up.
- Sort each new item: gap or wish? Gaps are part of shipping a product that works. Wishes are optional.
- Agree on it out loud. The document upload was agreed openly on a call, not slipped in quietly. That’s how a scope change should happen.
A scope that never changes usually means nobody has looked closely at the product yet.