Requirements change on most projects, and the process handles it rather than resisting it. Raise the change, we assess what it does to scope and timeline, and we come back with the impact in writing before anything is built. Small clarifications are absorbed. Anything that materially shifts scope or timeline is agreed with you first.
Not all changes cost the same, and knowing which is which helps you decide what to raise now versus park.
Usually inexpensive: adding fields, adjusting picklist values, changing labels and layouts, tweaking a notification, refining a report. These are configuration changes that do not disturb the underlying structure.
Usually expensive: changing the data model after build has started, adding a new integration, changing who owns which record, or introducing a second business process that the original design did not anticipate. These ripple into automation, permissions, reporting, and any migration mapping already done.
The expensive category gets more expensive the later it arrives, which is why structured requirements are returned to you for correction before build starts. That review is the cheapest moment to change your mind.
You raise it with your consultant. You get an assessment of the impact on scope, timeline, and cost. You decide whether to proceed, defer it to a later phase, or drop it. Nothing is built on a verbal change, which protects both sides.
Raise changes early and raise them out loud. Holding a concern until user acceptance testing is the most expensive way to change your mind, and it is also the most common.
To understand where changes are cheapest, read How does Cirro scope a project and produce an estimate?