Scope creep is the gradual growth of a project beyond what was agreed, through small additions that nobody priced or scheduled. Prevent it by writing down what is in scope and what is out, planning later phases for good ideas that can wait, and recording every change with its cost before work on it starts.
Every plan we write has a section for what we would leave out. Clients sometimes read it as a list of things we refuse to do. It is closer to the opposite: a list of things we thought about, took seriously, and decided should not be in the first version.
The list matters just as much on our own products, where there is no client to blame for additions. When you are both the customer and the developer, every extra feature feels free. It is not, and the launch date is where you find out.
Scope creep is rarely one large demand. It is a series of reasonable requests, each too small to argue about.
What is scope creep?
Scope creep is the unplanned expansion of a project after its scope has been agreed. It happens when features, pages, or requirements are added one at a time without adjusting the budget or the timeline. The individual additions are small. The combined effect is a project that is late and over budget.
The word "unplanned" matters. A project that grows because both sides agreed to add something, and adjusted the price and date to match, has changed scope. That is normal and healthy. Creep is growth that nobody decided on.
Why does scope creep happen?
Scope creep happens because good ideas arrive during a build, not before it. Seeing working software makes people think of improvements. Each one seems small, saying yes feels cooperative, and the original plan often never stated what was excluded, so nothing marks the request as new.
There are a few common sources:
- A vague plan. "A booking system" can mean a form or a full calendar with reminders and payments.
- No list of exclusions. If nothing is ruled out, everything is arguably in.
- Several people giving direction. Each adds requests without seeing the others.
- A developer who avoids awkward conversations. Quietly absorbing extras feels kind until the deadline arrives.
- "While you are in there." Nearby work looks free. It usually is not.
Notice that none of these involve bad faith. Scope creep happens on friendly projects more than hostile ones.
How do you prevent scope creep?
You prevent scope creep with a written scope, a written list of exclusions, and a rule that every change is recorded and sized before anyone starts on it. None of this requires refusing new ideas. It requires deciding about them on purpose instead of by default.
- Write the scope down. Short and specific. A list of pages, screens, or functions that someone could tick off.
- Write down what is out. This is as useful as the list of what is in. It settles arguments before they begin.
- Plan a second phase from the start. A good idea that is not urgent goes on the phase two list, which means it is recorded, not rejected.
- Name one decision maker. One person on the client side approves changes.
- Size every change before starting it. A sentence is enough: what it is, what it adds to the cost and the date.
- Trade, do not only add. If something new must go in and the date cannot move, something else comes out.
- Review against the plan at each round. Compare the working software to the written scope, not to memory.
Our post on writing a software project brief covers the first two in more depth.
What does a good phase one look like?
A good phase one is the smallest version of the product that does its main job completely. It leaves out features that are valuable but separable, and it names them as later phases. The test is whether a real customer could use phase one and get the central benefit.
Regulars is our loyalty product for smoke, vape, and CBD shops. Its job is to put a loyalty card in a customer's phone wallet and a message on their lock screen when there is a reason to come back. We shipped loyalty first and put payments in a later phase.
That was a deliberate exclusion. Regulars works with the shop's existing register, so a shop can use it without changing how it takes money. Payments would have been a second product with its own rules and its own risks, attached to the launch of the first. Keeping it out meant the loyalty part could be finished properly: the counter kiosk, the owner dashboard, the campaign scheduler, and the reports.
Deciding what counts as a first version is the subject of what an MVP is.
How should changes be handled once a build has started?
Changes during a build should be written down, sized, and accepted by both sides before work begins. The record states what is being added, what it does to the cost and timeline, and whether anything is being removed to make room. Small changes still get a line.
Here is how the options compare when a new request arrives:
| Option | Effect on date | Effect on cost | When it fits |
|---|---|---|---|
| Add it now | Later | Higher | The product does not work without it |
| Swap it for something in scope | Unchanged | Roughly unchanged | The new item matters more than an old one |
| Move it to phase two | Unchanged | Unchanged for now | Valuable, not urgent |
| Decline it | Unchanged | Unchanged | It does not serve the main job |
The third row is the one people forget exists. Most requests belong there.
Is all scope change bad?
No. Scope should change when you learn something that makes the original plan wrong. Building the agreed thing after discovering customers need a different thing is a worse failure than going over budget. The goal is deliberate change with known costs, not a frozen plan.
More features also mean more to test and maintain after launch. CoverageCobra, our marketplace for court appearance coverage, is the most heavily engineered thing we run: realtime matching, SMS and push alerts, transcribed voice notes, and a test suite that must pass before anything merges. Every one of those parts carries an ongoing cost. That is a reason to add features on purpose.
Frequently asked questions
Who is responsible for scope creep, the client or the developer?
Usually both. Clients add requests, and developers accept them without saying what they cost. The developer is better placed to stop it, because they know what each request involves, so the duty to speak up is mostly theirs.
Is a bug fix scope creep?
No. If something in the agreed scope does not work as described, fixing it is part of the original job. A request becomes new scope when it asks for behavior the plan never included.
What is gold plating?
Gold plating is scope creep that comes from the developer: adding polish or features nobody asked for. It delays the project just as client requests do, and it should be raised and agreed in the same way.
Does a fixed price stop scope creep?
It makes creep visible, because extra work has an obvious cost to someone. It does not stop requests from arriving. See fixed price vs hourly for how each model handles changes.
If you have an idea that keeps growing, send it to us. We will reply with what we would build first and what we would leave for later.