← All posts
ProcessContractsFAQ

What happens when we change our minds mid-build?

Wednesday 25 February 2026 · 3 min read · Rishi Gupta

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 → Not ready to talk? Take the eight-question AI assessment →
Keep reading
Can the software do the quote and a human just check it?
Sunday 18 October 2026 · 4 min
Nobody here will connect their inbox to an AI
Tuesday 13 October 2026 · 4 min
Can you make it talk to the system we already use?
Tuesday 6 October 2026 · 4 min