What happens when we change our minds mid-build?
You will change your mind. Everyone does, and usually for good reasons — you learn things once software is real that no amount of scoping surfaces.
How it works
Anything outside the agreed scope gets written down as a change, with what it does to time and cost, before anyone starts it. Then you decide: now, later, or never.
That sounds bureaucratic for small things and it is not — most changes take a sentence. The point is not paperwork, it is that nobody is surprised at the end.
Why I am strict about this now
Because I used to absorb changes silently to keep everyone happy. It felt generous. It was not.
The build ran late, and from the client's side there was no visible reason why, because nobody had recorded that the thing they asked for in week three was new. Silent absorption does not avoid the difficult conversation. It just moves it to the end and makes it worse.
The bigger risk
Scope creep is a delivery risk before it is a commercial one. Each addition mid-build is individually reasonable, and collectively they produce something heavier than the problem it was meant to solve. I have watched a build lose its users that way.
So the answer to most mid-build ideas is: yes, and that is phase two, once this is in real hands. Not never. Next.
Got a version of this problem? Twenty minutes minimum, seven questions, and a one-page Bottleneck Blueprint within 48 hours. If it's not a fit, we'll say so.
Book a call →