How to Control Revisions and Scope Changes During a Website Project

You approve the homepage, then ask for "a few small changes," and three weeks later the project has stalled with talk of an extra fee. You control revisions and scope by settling two things before the build starts: how many rounds of revisions are included, and what counts as changing agreed work versus brand-new work that needs its own quote. Every mid-build request then sorts into one of two boxes, a revision or new scope, and you both know which it is before anyone spends time on it.

This is for the owner who has approved a quote and wants the site delivered on budget and on time, without feeling awkward for asking for changes. Below is how revision rounds work, an in-scope versus new-scope guide, and a change-request checklist to keep the project tight.

TL;DR

• Two boxes: every mid-build request is either a revision (adjusting work already agreed) or new scope (work that was never quoted). Name the box before anyone starts.
• Revisions sit inside the rounds you agreed. New scope needs its own price and its own effect on the launch date.
• Pin down at quote: how many revision rounds are included, what a "round" actually means, and what the developer counts as new scope.
• Batch feedback into one consolidated list per round instead of a drip of one-off messages, which burns rounds and time.
• Use a written change request for anything that adds pages, features or a shop, so cost and timeline stay visible. On a TechTribe website, scope is set at quote stage, so there is a clear line to point back to.

What controlling revisions actually means

Controlling revisions is not refusing to change anything. It is agreeing, before the build, how changes are handled: a set number of revision rounds for adjusting agreed work, and a simple rule for spotting when a request is really new work in disguise. With that in place, you can ask for changes freely inside the rounds, and you only pay more when you genuinely add to the job.

Revisions and scope changes are two different things

Most budget and timeline blowouts come from treating these as the same thing. They are not.

A revision is an adjustment to work that was already in the quote. The page exists, the design is agreed, and you are refining it: fixing wording, swapping a photo, nudging spacing, correcting a colour. This is normal and expected. It is the reason revision rounds exist.

A scope change adds something that was never quoted. Three new pages, an online shop, a booking form, a property listings section, integration with another system. None of that was priced, so it cannot come free inside a revision round without someone absorbing the cost. That someone is either you, in an argument at the end, or the developer, who then rushes the rest to make the numbers work. Neither is good for the site.

The fix is to name the box out loud every time. Is this request adjusting something we agreed, or adding something we did not? Once that is a habit, "scope creep" stops being a vague fear and becomes a series of small, visible decisions you actually make.

In scope or new scope: a quick decision guide

Use this to sort a mid-build request before any work happens. It is a rule of thumb, not a contract, so confirm the specifics with your developer.

The pattern is consistent. If it lives inside the pages and features you already agreed, it is a revision. If it adds pages, functions or a section, it is new scope, and new scope earns its own quote and its own line on the timeline.

How revision rounds usually work

A revision round is one consolidated set of feedback that the developer works through in a pass, not an open tap of endless back-and-forth. You review the draft, gather every change into a single list, send it once, and that is one round. When the developer returns the updated version, you review again for the next round.

The number of included rounds varies by developer and by package. Some quote two or three; some handle it more loosely. There is no universal standard, so do not assume it is unlimited and do not assume it is one. TechTribe, like most developers, works to a defined number of revision rounds per project, and the right time to confirm the exact number for your package is when you get a quote, not halfway through the build.

Two habits protect your rounds:

• Batch your feedback. Ten separate WhatsApp messages over three days, each with one tweak, can eat a whole round and stall the build while the developer waits to see if you are finished. One clear list of ten items is far cheaper in time and goodwill.
• Be specific. "Make it pop" forces a guess and often a re-do. "Make this heading larger and move the WhatsApp button above the fold" gets it right the first time.

If you run out of included rounds, that is not a disaster. It just means further changes are quoted as extra work, which is fair, because they are extra work. Knowing where that line sits is the whole point of settling it early.

The change-request checklist

For anything that looks like new scope, or any change you are unsure about, run it through this before work starts. It keeps the addition a decision, not a surprise.

• What exactly is changing, written in one or two plain sentences
• Whether it is a revision inside an agreed round, or new scope
• If it is new scope, the price for it, agreed in writing before anyone builds
• The effect on the launch date, stated as clearly as the price
• Who on your side signs off the change (one named person)
• Confirmation the rest of the project stays on its original terms

A short written note covering those six points, even a single message you both reply to, is enough. The value is not the paperwork. It is that cost and timeline stay in front of you while you decide, instead of arriving as a shock at handover.

What this article does not cover

Two neighbouring problems get their own guides, because mixing them in here would blur the advice.

If your project is drifting for reasons that are not about changing the scope, such as content that never arrives or approvals with no clear owner, that is a delay problem. Read why website projects run late in Zimbabwe for the causes and the fixes.

And the best way to reduce scope changes is to get the scope right before quoting, which is a job you do up front. Our website brief template for Zimbabwe businesses walks through what to prepare and send, so fewer things surface mid-build as surprises in the first place.

How this works with a TechTribe website

TechTribe general business websites are quoted once-off, with the pages and features set at the start, so there is always a clear scope to measure a change against. Starter is $350, Standard is $550, and Premium starts from $800 with a custom quote after scope. You can see what each package includes before you commit.

Because the scope is written down at quote stage, a mid-build request is easy to place. Refining an agreed page is a revision. Adding a small shop or extra pages usually moves you from Starter toward Standard or Premium, and that gets its own price rather than being squeezed into the original figure. Separate add-ons work the same way: extra written content and professional photography are quoted as their own line items, not folded silently into a revision. When you get a quote, ask us to confirm the number of revision rounds and what we treat as new scope, and you will have the two lines you need to keep the project on budget and on time.

Your next step

Controlling revisions and scope is mostly one discipline done early: agree how many revision rounds you get and what counts as a change, then sort every mid-build request into a revision or new scope before the work starts. Do that, batch your feedback, and put anything new in a short written change request, and the project stays inside the numbers you agreed.

If you want a website where the scope, the revisions and the price are set out plainly from the start, request a quote and ask us to spell out exactly what is included and what would count as a change.

---

Author: Simon Updated: April 2026