A client came to me in March with a project that had a six-week estimate. We are now in month four.
Nothing went wrong, exactly. Nobody missed a deadline through laziness or bad code. What happened is more common than that, and more expensive. Along the way, my client kept adding "just one more small thing." A field here. A button there. An extra report nobody asked for at the start. Each request felt tiny on its own. Together, they turned six weeks into four months.
I see this pattern often enough that I have a name for it: feature creep. And I have learned that the most valuable sentence I can say to a client, mid-project, is "not yet."
This article explains why small additions during a project rarely stay small, why saying "not yet" protects you rather than slows you down, and how to keep new ideas moving without wrecking the project you already started.
Why one small request never travels alone
When you ask for a "small" addition, you are not just asking for that one thing. You are asking me to touch code that already works, that has already been tested, and that other features already depend on.
Software is more connected than it looks from the outside. A change to how the sign-up form saves an email address might touch the welcome email, the admin dashboard that lists new customers, and the report your bookkeeper pulls every month. Add a field, and I need to check all three. Add five fields over five weeks, and I need to check all three, five separate times, while also building whatever we agreed to build in the first place.
This is why a task that looks like "an hour of work" often becomes a day. The hour is real. The day is the hour plus the re-testing plus the fixing of whatever the change quietly broke somewhere else.
The math behind "it's just a small thing"
This isn't just my experience. Research from the Project Management Institute found that just over half of all projects experience scope creep, the slow, steady growth of requirements after work has already started. High-performing organizations are more than twice as likely to keep it under control as low-performing ones. That gap is not luck. It's discipline.
Industry estimates on cost growth make the same point in blunter terms: a scope increase of around 10 percent can push total project cost up by 30 percent or more. The extra cost comes from exactly what I described above: redoing designs, running another round of testing, updating documentation, and fixing the ripple effects nobody planned for.
None of this means new ideas are bad. It means they carry a bill that's easy to underestimate when you're only looking at the idea in isolation.
Why "not yet" is protection, not resistance
When I tell a client "not yet, let's finish this first," I'm not being difficult. I'm protecting three things: the budget you agreed to, the date you're planning around, and the stability of the thing we're building right now.
Every time we stop mid-project to build something new, we lose our place in the original work. We context-switch. We risk half-finished pieces sitting untested while attention moves elsewhere. And we make it much harder to know, at any given moment, when the project will actually be done, because the finish line keeps moving.
A good developer who says "not yet" is telling you this idea is worth doing well, and doing it well right now, in the middle of something else, isn't the way to get that.
An everyday example
Say you're building a booking system for a small clinic. Halfway through, you think: it would be great if patients could also leave a note about why they're coming in. Simple enough, right? One more text box.
But that note needs to show up somewhere useful: on the receptionist's screen, in the reminder email, maybe in a report the doctor reviews before appointments. It needs a length limit so nobody pastes in three paragraphs. It needs to work in Spanish and English if your other fields do. And now the appointment confirmation screen, the email template, and the admin view all need testing again, because all three touch the same booking record.
That's not a one-hour add. That's a real feature, and it deserves its own space, not a rushed detour in the middle of building the booking flow you already agreed on.
Keep the idea. Don't chase it yet.
The answer isn't to say no to good ideas forever. It's to write them down.
I keep a running "next" list for every project I work on. When a client has a new idea mid-project, I add it to the list with a short note about why it matters. Nothing gets lost. Nothing gets forgotten. It just waits for its turn, right after we ship the thing we started.
This does two things. It gives the idea the attention it deserves, once we can actually focus on it properly. And it keeps the current project moving toward an actual finish line, instead of drifting further every time someone thinks of something new.
If you want a head start on separating "must launch now" from "worth adding later," I've written about the most common mistakes business owners make before a project even begins, and about building software in stages so it can grow without a rebuild. Both connect directly to this idea: the smartest move is often building less, on purpose, right now.
What this protects
A project with clear boundaries ships. A project that absorbs every new idea as it arrives tends to drift, quietly, until nobody can say when it will actually be done.
"Not yet" is not a wall. It's a placeholder. It means yes, and, after we finish what we promised each other first.
If you're mid-project right now and the list of "just one more things" keeps growing, that's a good moment to pause and sort them, not to keep adding.