The Change Order Template for a Claude Code Project (Five Fields, One Page)

What a Change Order Is and Why Builders Skip It

A change order is a short written amendment to the agreement you already have with a client: what the new request is, what it costs, what it does to the timeline, and a place to say yes. It gets sent before the new work starts, not after, so the price is agreed while the request is still just a request.

Most builders skip it for a reason that sounds reasonable in the moment: the request seems small, saying yes is faster than negotiating, and asking for money over what feels like a minor add-on seems petty. That reasoning is how a two-week build becomes a five-week one at the original price, one small yes at a time.

The deeper problem is that skipping the change order is not a neutral choice. It quietly teaches the client that new requests are free, which trains them to keep making them, and it puts you in the position of either eating the cost silently or bringing up money after the work is already done, which is a worse conversation than the one you avoided.

The Five-Field Change Order

Write the change order in five fields, in this order: the request, the reference, the cost delta, the timeline delta, and the sign-off. This is the Five-Field Change Order, and the sequence is deliberate: it moves from agreement to number, not the other way around.

Keep the whole document to one page. A change order that reads like a new contract invites a client to renegotiate the entire relationship instead of approving one specific addition, which is the opposite of what you want from a document meant to move fast.

Field One and Two: Name the Request, Point at the Reference

Write the request back in the client's own words first. This does two things: it proves you understood the ask correctly before any number appears, and it removes the chance that a misread request turns into a priced misunderstanding.

Then point at what it changes. Reference the original scope document directly, whether that is a [one-page agreement](/blog/one-page-agreement-before-you-build) or a [statement of scope](/blog/scope-of-work-that-prevents-scope-creep): name the section the new request falls outside of. This is the field that turns 'can you also add' into a documented change rather than an argument about memory, because the boundary is written down and you are simply pointing at it.

Field Three: Price the Delta, Not the Whole Project

Price only the new piece, using the same method you used to [estimate the original build](/blog/estimate-a-claude-code-build). A change order is not the moment to renegotiate your whole rate; it is the moment to price one specific addition on top of an engagement that is already priced.

• State the delta as a number, not a range. A range invites negotiation on a request the client already agreed they wanted.
• If the change affects a milestone payment schedule you already agreed, say so explicitly rather than let it surface at the next invoice as a surprise.
• For small changes, a flat add-on price is faster to approve than a detailed breakdown. Save the breakdown for changes big enough that the client will ask for one anyway.

Say the number plainly and once. A change order that hedges on price reads as uncertain, and an uncertain price is the easiest one for a client to talk down.

Field Four: The Timeline Delta

State the new delivery date, or say plainly that the original date holds if the change genuinely does not affect it. Do not leave this field blank. A silent timeline is the single most common source of a client believing a change order was free of consequence when it was not.

This field also protects you the other direction. Once it is written down and agreed, a later complaint that the project is running long has a documented answer: the date moved because of a specific, signed-off addition, not because the original estimate was wrong.

Field Five: The One-Line Sign-Off

End with a single line: approved, a date, a name. That is the entire mechanism that separates a change order from a conversation that quietly became an agreement nobody actually confirmed.

Do not start the new work before that line comes back. This is the rule builders break most often, usually because starting feels like good service and waiting feels like friction. It is the opposite: starting before sign-off puts you in the position of having done unpaid work if the client hesitates on the price, which is a worse outcome than a day's delay.

When to Send One, and When to Just Absorb It

Not every request needs a change order. The threshold: if honoring it costs you more than an hour of real work, or pushes a date, it gets one. Anything smaller, absorb it without ceremony and move on.

1. A typo fix, a color tweak, a copy change on an existing page: absorb it. Sending a change order for something this small reads as nickel-and-diming a client you are trying to keep.
2. A new field on an existing form, a small logic change to existing behavior: judgment call, usually still absorbed if it is genuinely quick.
3. A new page, a new integration, a new report, anything that touches [payment milestones](/blog/structure-client-payments-milestones): change order, every time.
4. Anything the client frames as urgent or as a rush: change order first, even if you would have said yes anyway, because urgency is exactly when scope and price get skipped under pressure.

What Skipping It Actually Costs You

The cost is not just the unpaid hours on this one request. It is that every unpriced yes lowers the client's expectation of what a new request costs, which compounds across the engagement. By the time a project is genuinely [over budget](/blog/when-a-claude-code-build-runs-over-budget), it is rarely one bad estimate. It is usually a dozen small unwritten yeses that never got a number attached.

It also removes your only clean way to have the budget conversation later. A change order history is evidence the project grew because the client kept adding things, each one agreed and priced in writing. Without it, a project that ran long just looks like it ran long, and the reason is a much harder case to make after the fact than it would have been in writing at the time.

Common Change Order Mistakes

Most change orders that fail to get a fast yes fail for one of these reasons.

1. Sent after the work was already done. This is not a change order, it is a surprise invoice, and clients respond to it accordingly.
2. Written as a renegotiation of the whole project instead of one addition. Keep it to the delta.
3. No reference back to the original scope, so the client cannot see why this is new work rather than something they assumed was already included.
4. A hedged, ranged price instead of a plain number, which reads as unsure and invites a lower counteroffer.
5. Starting the work before the sign-off line comes back, which erases the entire point of having a sign-off line.

Read a change order back once before you send it and ask whether it would take the client under two minutes to approve. If the answer is yes, you have written a good one.