What happens if our requirements change in the middle of a custom build?
How change requests are handled without blowing up the timeline or the budget.
Requirements change on every project, and that is normal. What protects the launch date is a written change request, an honest estimate of its impact on scope and schedule, and a decision by you about whether it goes in now or in phase two.
The process
- Write it down. A change discussed on a call and never documented is how two people end up with two different projects.
- Estimate the real impact. Not just the hours to build it, but what it touches: testing, data migration, anything already built that has to be reworked.
- Price it and date it. What it costs and what it does to the timeline, in writing, before anyone starts.
- You decide. Approve it, defer it to phase two, or drop something of similar size from the current phase to make room.
Why absorbing changes quietly is the actual danger
The failure mode people expect is an agency nickel-and-diming them for every request. The far more common failure is an agency saying yes to everything to stay agreeable, absorbing a dozen small changes, and then missing the launch date without ever explaining why. You never got to choose, because you were never told what the choices cost. A change request process is not bureaucracy, it is how you keep control of your own project.
What does not need a change request
Being specific here matters, because an agency that raises a change order for a button color is just being difficult. Clarifications, corrections to something that was always in scope, bug fixes, and small refinements found during review are part of the work. A change request is for new functionality, a different integration, a new user role, or a shift in the underlying requirement.
How to reduce them before they happen
Most mid-build changes come from one of two things: a stakeholder who was not in discovery, or a requirement that nobody could evaluate on paper. Fix the first by getting every decision-maker into discovery once, early. Fix the second by phasing, and by putting something usable in front of people quickly, because people are far better at reacting to a working screen than at reading a specification. That is the same reason prototypes are worth the time, discussed in web design vs product design.
Ongoing change capacity after launch usually lives on a monthly retainer, listed on the retainers page.
Related: Does LevelUp Digital build custom web applications?. How long does a custom integration project take?. Can you add custom features to our existing website?.