Every project changes shape while it is being built. The question is never whether but when you notice, and the cost curve for that is steep: a change in week two is a conversation, the same change in week seven is a rebuild.
Why late changes cost so much more
Software is layered. A decision about how orders are stored shapes the screens, the permissions, the reports and the integrations built on top of it. Changing it in week two touches one layer. In week seven it touches everything built since — which is why a request that sounds identical to you can be a day or a fortnight depending only on the date.
This is also why "we will decide that later" is rarely free. Deferring a decision means everything built meanwhile assumes something, and the assumption is invisible until it is wrong.
Set the project up to surface changes early
Something you can open every week. Not screenshots, not a status call — a link. Most changes of mind are triggered by seeing the thing, and the earlier you see it the cheaper they are.
Your own people using it before it is finished. A week of real use catches more than any review meeting, and the earlier it can be arranged the better.
Decisions written where both sides can see them. Not to enforce anything, but so that when something changes, everyone can tell what else it touches.
What to expect from a studio
Changes inside the agreed scope should be absorbed without drama — that is normal work, not an event. Changes that replace agreed scope should be priced before anyone touches them, in writing, with an honest note about what it does to the date.
What you should not accept is silent absorption. A studio that says yes to everything and never mentions the cost is not being generous — it is spending the buffer, and the bill arrives as a missed deadline in the final week when there is no room left to react.
And the change worth making
Occasionally the honest answer is that the original plan was wrong. Not adjusted — wrong. Discovering that in week three of eight is the cheapest possible version of that discovery, and a project structured to make it visible has done you a service, even if it feels at the time like failure. Better to spend eight weeks proving an idea does not work than a year proving it slowly. That is why the first version is scoped to one journey: the cheapest way to find out you were wrong is to find out early.
On the same decision, from another angle: what handover actually includes, and what it usually does not.