The build was small. That was the whole appeal. One paragraph of brief, a number you were comfortable quoting, a couple of weeks.
Then the requests arrive. Can the manager also export that list. Can the logo sit on the left. Can there be a second kind of user for the warehouse team. Not one of them is big, and not one is worth an argument with a client you want to keep.
So you absorb them. That’s how scope creep works on a small build: never one large change, always a run of changes too small to bill for and too many to eat.
Which is why the answer to how to stop scope creep on a small build sits upstream of all of it, before anyone writes code.
Saying no harder doesn’t work
The standard advice is to hold the line. Push back. Get every change request in writing.
Try that on a two-week project. There’s no steering committee to escalate to and no change-control process, because standing one up costs more than the change did. What there is: you, a client and two versions of a conversation you both half remember.
That’s the real problem. When a request lands, you have nothing to measure it against. Was a second user role in the original scope? You’re fairly sure it wasn’t. The client thought it was obvious. Neither of you is lying, and no document settles it.
So both of your options are bad ones. Absorb the work and lose the margin, or push back and become the person who says no, with nothing to point at but your own memory.
Scope creep isn’t a failure of discipline. It’s what happens when “done” was never defined.
Three places a small build leaks
It’s the same three every time, and all three are sitting in the brief before the project starts.
The verb that hides three features. “Users can manage their profile.” Manage means view. It almost certainly means edit. It may mean delete, and if it does, somebody has to decide what happens to the records attached to that profile. And does an admin manage other people’s profiles too? One word, four builds, one of which you quoted for.
The role nobody named. The brief says “users”. Halfway in you discover there are managers and there are warehouse staff. They see different things. One of them approves what the other submits. Every screen you already built now has a permission question hanging off it.
The state nobody described. The empty list on day one. The upload that’s too large. The double click that submits the order twice. That work exists whether or not anyone mentioned it. The only open question is whether it was in scope when the number was agreed.
None of this is exotic. It’s the ordinary content of a small build, and it’s invisible while the brief is still a paragraph.
”Done” has to be checkable, or it isn’t a definition
A requirement you can’t check isn’t worth writing down.
“The client can export orders” looks like a definition and settles nothing. Export which orders? Over what date range? Can a warehouse user see the button?
Here’s the same requirement written so someone can check it: a logged-in manager clicks Export on the orders list and gets a file of that month’s orders, and a warehouse user doesn’t see the button at all.
Now put a change request next to that. “Can we get last quarter too?” is visibly a different requirement, not a reading of the one you agreed on. Establishing that took no argument and no email thread. The definition did it.
That’s what a testable requirement is worth on a small project. It isn’t paperwork. It’s something to point at.
Getting the definition written before the code
At TalkIDE this is a stage of the work, not a document you’re asked to go away and produce.
You start by talking to Vera, and you bring what you want in whatever order it comes out in. Her job is to turn that into shape: who else logs in besides you, what each of those people is allowed to see that you can’t, what happens to a record when somebody’s account closes. None of that was in your one-paragraph brief. All of it turns into a change request in week two if nobody asks now.
You don’t sign off on a page of text, either. Remy builds a clickable mockup from that conversation and Otto deploys it, so what comes back to you is something you can click through. “That’s not what I asked for” is a sentence worth hearing at that point in a software project. There, it costs another conversation. Said about a finished build, it costs a rebuild.
Once you’re happy with what you clicked through, you trigger the hand-off yourself. That’s when Mara’s team takes the project, and Iris, the Analyst on that team, turns the mockup and the conversation behind it into a set of requirements a stranger could build from and land on the same result. Checkable in the sense above: each one names something somebody can point at, not a description somebody has to interpret.
Vera is the default route, not a toll gate. If you already know exactly what you want, you can skip the conversation and start straight with Mara. The same scoping-first shape is what we describe in an AI builder that scopes the project with you.
None of that stops a client from wanting something new. Nothing does, and a process that claimed otherwise would be lying about how projects work. What changes is what the wanting turns into.
What happens to the next change request
Requests still come. They land somewhere different.
Against a written definition, a request resolves into one of three things.
- It’s already in there. Build it. It was in scope the whole time and nobody needs a conversation about it.
- It isn’t in there. Now it’s a decision: in or out, and what it adds to the work. That’s a scoped conversation with a client, not a dispute about what was meant six weeks ago.
- It contradicts something in there. You’ve found a genuine conflict in the requirements, and you’ve found it while resolving it is still cheap.
You stop being the person who says no. You become the person who says what it costs.
That’s also the honest answer to why software projects miss deadlines. When a small build misses its date, the work is rarely the reason. The project being delivered got bigger than the project that was estimated, one reasonable request at a time. Nobody can point at the moment it happened.
Some requirements only surface once the thing is real and someone is clicking around in it. That isn’t creep. That’s a live product, and it runs through a different loop: what happens to change requests after a working delivery.
See how a project gets scoped
Defining “done” before the build isn’t extra process. On a small project it’s the only process you get, and it’s the difference between a change request and an argument.
See how a project gets scoped.
The Mara team.