You may be charged extra for changes during a website build, but only when the change falls outside the agreed scope or exceeds the included revision rounds. Small corrections within the plan are usually part of the job. New pages, new features or a change in direction after approval are the requests most likely to carry a fee.
That answer depends on what you agreed at the start. A clear scope, revision allowance and change process make the rules visible before anyone feels caught out. Without them, both sides end up arguing about what was assumed.
What usually counts as an included change
Most website projects expect feedback. You see a design, ask for adjustments, then review the built pages and spot items to fix. Typical included changes are corrections to spelling, swapping an image you supplied, tweaking colours within the agreed style or rearranging content on an approved page.
Many quotes include a set number of revision rounds at each stage. A round normally means collecting all feedback into one list, sending it, then reviewing the updated version. Sending one comment on Monday, another on Wednesday and a third on Friday may each count as a separate round, depending on the agreement.
Fixing work that does not match the agreed specification is different again. If the brief said the enquiry form would send to two email addresses and it sends to one, that is a defect to fix, not a change request.
What is likely to be charged as extra
Charges usually apply when the request adds work the designer did not price. Examples include adding pages, building a booking system that was not in scope, connecting new software, creating extra landing pages or redesigning a page after you approved it.
A change in direction is the costly one. Suppose a Perth landscaper approves a calm, earthy design, then asks for a bold new style after seeing a competitor’s site. Even if the page count stays the same, the designer may need to redo templates and rebuild components. That is not a tweak.
Late content can create extra work too. If finished copy arrives after pages are built and needs a different layout, the designer may have to rebuild sections. Ask how your provider handles that before the project starts.
Why scope protects you as well as the designer
A detailed scope can feel like paperwork, but it keeps the project price meaningful. It names the pages, features, revision rounds and responsibilities included in the quote. When a new idea comes up, both parties can see whether it changes the job.
Ask the designer to put assumptions in writing. Who supplies copy and images? Which forms or integrations are included? How many rounds of design and build feedback do you get? What happens if feedback arrives late? These details make the eventual change discussion simpler.
A sensible scope also leaves room to improve the site. You may discover during the build that a page needs a clearer call to action or that one service deserves its own page. A good process lets you decide whether the benefit is worth the added cost and time.
How a fair change request process works
The designer should flag that a request sits outside scope before doing the work. They should explain what is changing, the estimated cost, any impact on the launch date and whether existing work must be redone. You then approve or decline in writing.
The change can be priced as a fixed amount, an estimate based on hours or a trade within the existing budget. Sometimes you can swap one feature for another of similar effort. Sometimes the best answer is to launch on schedule and add the new idea afterwards.
That last option matters. Not every good idea needs to go into the first release. If the change would delay a launch tied to a campaign or season, park it for a planned update after launch.
What changes after launch look like
Changes after launch are a separate conversation. Once the site is live, small content edits might be included in a maintenance plan, quoted as one-off work or handled by your team if you have editor access. Agree that arrangement before launch so the first post-launch request does not become a negotiation.
Before handover, ask which changes you can make yourself, who can train your team and whether your maintenance agreement covers content changes or only technical upkeep. Replacing a staff photo is not the same job as adding a booking flow. A provider should be able to explain how each sort of request is handled without promising that every future edit is free.
Keep a short list of non-urgent improvements and review them together after the site has been used for a while. You will have real customer questions and enquiry patterns to guide what changes first. That is usually more useful than adding every idea before launch.
How to keep change costs under control
Do the thinking early. Gather the services, locations, proof and contact options your site needs before design starts. Show examples of sites you like and explain why. Make sure the person who will approve the final site sees the plan early, not only at launch.
Consolidate feedback. Agree who gives it, collect comments from your team and send one clear list per round. Mark each item as a fix, a preference or a new request. That helps the designer act quickly and price only what is new.
Read the scope before approving each stage. Approval signals that the project can move on. If you are unsure, ask before approving rather than after the next stage is built. Our website design and development process explains the stages where these decisions happen.
Frequently asked questions
Is a bug fix a change request?
Usually not. If the site does not work as described in the agreed scope, fixing it should be part of the job. A request for different behaviour from what was agreed is a change.
Can I approve a design and still change it later?
You can ask. If the change affects work already built or approved, the designer may quote it as extra because it creates rework.
How should I give feedback during the build?
Send one consolidated list per round, ideally with page names, screenshots and clear instructions. Specific feedback is quicker to act on and reduces misunderstandings.
Agree the change rules before the build starts
A clear change process helps you improve the site without losing control of the budget or timeline. If you want to plan your next website project properly from the start, book a discovery call.
