Client keeps adding features mid-project

The build was scoped in March and the requirements have been arriving ever since, one Slack message at a time. Below is the sort that tells you which reply each one gets, the change-order email for the big ones, and how to move the rest into a phase 2 the client is happy to pay for.

Sort every request before you answer it

The reason feature creep works is that each request looks small on its own. Sorting is what stops that. Three sizes, and the test for each is mechanical enough that you can do it while reading the message.

If you can’t tell small from big, it’s big. If you can’t tell tiny from small, it’s small. The failure mode is always guessing downward.

On a software build there are two things the sort will catch that a gut call won’t. The first is the request that is small to build and large to maintain: an extra user role, a second login method, a new state a screen can be in. Every one of those multiplies your test surface for the rest of the project, and it belongs in the big bucket even when the ticket looks like an afternoon. The second is the request that is small in isolation and big in sequence. The fourth “can we also” of the month is not a fifteen-minute task; it’s the fourth interruption to a schedule that was built without any of them.

Whatever the bucket, price from a rule you set in advance rather than a number you invent while annoyed. The kit’s pricing rules use a change rate you set once, a half-day minimum on anything you price at all, and a rush multiplier for work that has to jump the queue. On a $120/hr change rate that half day is $480, and it is the floor for a “quick” feature, because a forty-five minute change costs you the reading, the context reload, the doing, the testing, the deploying, and the follow-up question.

The reply for the small bucket

This is the one you’ll send most often, and it takes about ninety seconds.

The timeline line matters more than the price on a build. A client who is spending someone else’s budget will approve costs all day and will stop dead at a date that moves past a launch they’ve already announced. Putting both in every reply hands them the trade-off, and after two or three of these most clients start sorting their own requests before sending them.

Don’t start until the yes is in writing. A thumbs-up on the Slack message counts. A verbal “yeah go for it” on a call does not, and the version of this where you build it first and invoice after is the one that ends in an argument.

The change order, and how to pause without stopping

For anything over a day, the price goes in a one-page change order instead of an email bullet. The form exists to force the three questions that scope creep skips: what exactly, how much, by when. The kit’s template covers the original proposal reference, the concrete work involved, the price with a cap if it’s hourly, the new delivery date and which milestones move, and an explicit “not included” list naming the next three things the client will ask for. Number them per project, CO-01 onward. Hitting CO-04 on one project is a signal to talk about the account rather than the change.

Then the hard part. Clients say “go ahead” and don’t sign, and if you build on a verbal yes you have donated the work. Script 14 handles it.

The sentence that makes this safe to send is “the original scope continues and isn’t affected.” You are pausing one feature, not the project, so nothing about the message is a threat. Mean it, though. The first time you pause and stay paused, every future change order from that client comes back inside a day.

Batch the rest into a phase 2

Half the requests on a growing build aren’t urgent and don’t belong in the current sprint. Rather than pricing each one as it lands, keep a visible list and let it fill up.

• Log every request the moment it arrives, in a shared doc the client can see: what was asked, the date, who asked, your rough size. A request that is written down stops being a thing they need to keep chasing you about, which cuts the number of follow-up messages sharply.
• Reply the same day with the bucket, not the price. “Added to the list as a medium. It’s outside the current scope, so it lands in phase 2 unless you want it now, in which case I’ll price it.” About half the time nobody wants it now.
• Propose phase 2 once the list has five or six items on it. One scope, one price, one timeline, starting after the current launch. Clients approve a bundled phase far more readily than the same features priced individually, because it reads as a plan rather than as a run of surcharges.
• Say which items you would drop. Recommending against two of the six buys you enormous credibility on the other four, and the client stops reading the list as an upsell.

The list also settles the arguments. When a client asks why the launch slipped, the log has fourteen dated entries on it, and the answer stops being a matter of opinion. Send it as a summary at the end of every fortnight whether or not anything is pending.

Some additions genuinely improve the product, and script 11 in the kit is for those: agree enthusiastically and price it in the same message. Splitting them, with “great idea” today and “about the cost” tomorrow, is what makes the second message feel like a bait and switch.

The change order template, all fourteen scripts and the scope-definition clause that keeps the next build from doing this are in the $12 kit.