Requirements change. That is normal and we plan for it. What matters is handling changes visibly rather than absorbing them silently until the schedule quietly collapses.
Changes within scope
Refinements to agreed work are part of the process. Adjusting colours during design review, rewording content, repositioning a section, swapping images. These are expected and included within the review rounds set out in your quotation.
Changes that expand scope
Anything that adds work beyond what was quoted is a change request:
- Additional pages or templates.
- New functionality that was not in the specification.
- A design direction change after a design was approved.
- Adding a language, an integration or a payment method.
- A significant increase in content volume.
How we handle it
- You raise the request in the portal at crm.zylax.com.my or on your project thread.
- We assess the impact on cost and on timeline. Timeline matters as much as cost and is often the part people forget.
- We send a written change note with both figures.
- You approve or decline. Nothing is built and nothing is billed until you approve.
The trade offs
Changes late in a project cost more than the same change early, because approved work has to be undone. A design change during wireframing is cheap. The same change after development is expensive. If you are unsure about something, raise it at the earliest stage you can.
Phase two is a real option
Not everything needs to be in version one. Launching on schedule with a solid core, then adding the extras as a second phase, is usually better than delaying launch for months while scope grows. We will often recommend this.
Timeline effects
Approved changes move the launch date. We will tell you by how much at the time of approval, not afterwards.
To raise a change request, reply to your email thread or contact [email protected].
