The Best Dev Shops Don't Say No. They Say Phase 2.

Near the end of a build, the feedback list changes character. For weeks it reads like a punch list: fix this, adjust that, this label is wrong. Then a list comes in with a different kind of item mixed into it. Alongside the real fixes are two or three things that are not fixes at all. They are new. New capability, new screen, new idea that was never in the plan. On the page they look identical to everything else. One line each, same tone. And the whole timeline that week depends on noticing that they are not the same.

This is one of the most underrated moments in building software, and almost nobody talks about it. Every founder worries about scope creep at the start, during the big kickoff conversation about features. Almost no one watches for it where it actually happens, which is here, in the ordinary back-and-forth of a build that is going well. Scope does not creep in through a formal request. It arrives disguised as a small note on a list you were already reviewing.

When a new request shows up in the middle of a build, a shop has three ways to respond, and only one of them is right.

The silent yes is the one that gets you

The first response is the silent yes. The request looks small, the relationship is good, and saying "sure, we can fit that in" feels like exactly the kind of responsive partner you want to be. So the item goes into the build quietly, with no conversation about what it costs, and everyone moves on feeling good about it.

This is the response that wrecks projects, and it wrecks them precisely because it feels generous. A silent yes has no price tag attached, so nobody sees the bill until the date slips. Then it slips again. The founder cannot understand why, because from where they sit nothing dramatic happened. There was no giant new feature. There were just eleven small yeses that each felt free and none of which were. Speed is focus, and a silent yes is focus leaking out one polite agreement at a time.

The flat no is not the fix either

Knowing that, some shops swing to the other extreme and treat the original scope like a contract to hide behind. Anything not on the list gets a flat no. Out of scope. Put it in a ticket. This protects the timeline, and it is a miserable way to build something with someone.

A flat no assumes the new idea is noise. Usually it isn't. Usually the founder is seeing their own product more clearly than they could at kickoff, because now there is a real thing in front of them to react to. Some of the best features in things we have built showed up exactly this way, as a mid-build "what if we also." Rejecting those on principle means the person who understands the product best becomes the person least able to change it. That is backwards.

The move is to place the request, not judge it

The right response is neither yes nor no. It is a question about timing. Yes, that is a real idea. No, it does not belong in Phase 1. Here is the phase it belongs in, and here is what putting it in this one would cost you.

That framing does three things at once. It takes the idea seriously, so the founder feels heard instead of managed. It protects the thing that has to happen, which is getting a working first version in front of real users. And it turns a vague anxiety about scope into a concrete, honest choice the founder gets to make with real information in hand: this idea, or this date. You cannot have both, and now you know it, so you get to decide on purpose.

We closed out a Phase 1 this way on an internal tool a business runs its daily numbers through. The final round of feedback had exactly this mix on it: a stack of genuine fixes and refinements, and a few items that were new capability wearing the same clothes. So we drew the line out loud. The current list is the final scope for Phase 1. The genuinely new ideas got written down and set up as their own later phase, not folded in quietly. That one distinction is what let Phase 1 actually end and move into a calmer maintenance rhythm, instead of becoming the kind of build that never quite finishes because the finish line keeps sliding.

You can only place a request if you know what "done" means

None of this works without one thing in place before the requests ever arrive: a real definition of done for the phase you are in. Not a vague sense of it. A written one. If Phase 1 has an actual boundary, sorting a new request is easy, because you can hold it up against that boundary and see right away which side it falls on. If Phase 1 has no boundary, every request looks reasonable, because there is nothing to measure it against. This is why scope is the product. The list of what you are deliberately not building yet is doing as much work as the list of what you are.

So here is what to watch for, whether you are choosing a shop or already deep in a build with one. Hand them a mixed list and see what they do with it. Do they sort it, or do they swallow it? A shop that swallows everything is not being nice to you. It is quietly spending your runway and your launch date to avoid one uncomfortable sentence. A shop worth keeping will say the uncomfortable sentence. It will tell you which items are fixes and which are new, which ones move your launch date and which ones don't, and it will make you choose on purpose instead of by accident.

The new ideas are not the enemy of your MVP. Unplaced ideas are. Give every "can we also" a home, and most of them turn out to be worth building, just not yet.