"Can You Just Add One More Thing?" — How a Change Request Travels From a Sentence to Production

One casual sentence, forty billable hours later

On an e-commerce admin project two years ago, a client said in the last two minutes of a weekly call: "Could you also make coupons stackable?" It sounded like a ten-minute job. It actually touched cart calculation, refund splitting and reporting, consumed 40 engineering hours and pushed the launch out by 11 days. The real damage was not the 40 hours — it was that the request was never written down, never quoted, never confirmed by anyone. Once the launch date passed, the two sides had completely different memories of what had been agreed. Since then one rule at ScriptWalker never bends: anything outside the original spec goes through a change request.

What we do: a sentence becomes a numbered ticket

Every request beyond the original spec passes eight gates. There is no verbal version and no exception — from the moment that sentence is spoken it has a number you can search for:

A sentence from the client (weekly call / chat / email)
    ↓
Slack #cr-inbox: ticket opened within 24h
    ↓
Notion change request CR-2026-041 (13 fields)
    ↓
Grade A / B / C (hours + risk surface)
    ↓
Impact assessment (modules / data / tests / docs)
    ↓
Quote + schedule (mandatory for B and C)
    ↓
Written client confirmation (email reply "approved")
    ↓
GitHub Projects → sprint → PR → acceptance
    ↓
Write back spec + CHANGELOG → close ticket

Why it is built this way: three trade-offs

Speed versus traceability. Pushing small changes through the full pipeline would strangle them, so we kept a Grade A fast lane: just do it, open the ticket anyway, but do not let the paperwork block anyone.

A free allowance versus a firm boundary. With no free allowance, clients feel every sentence costs money, so eventually they stop speaking and the requirement surfaces after launch instead. Grade A therefore carries 8 free engineering hours a month.

Grade by hours, not by "importance." Importance is subjective; hours are negotiable:

Grade	Criteria	Handling
A	≤ 2 hours, no schema change, no payment or permission code	Absorbed into the current sprint at no charge (8 hours/month cap)
B	2–16 hours, or touches 2+ modules	Impact assessment and quote, scheduled into the next sprint
C	> 16 hours, or changes the data model, payments or permissions	Treated as a new phase: timeline re-estimated, contract addendum signed

How it runs: the tools and the form

Four tools carry the chain. Slack Connect gives us a shared #cr-inbox channel where the client's marketing and ops people can drop requests directly. Notion stores the tickets and auto-numbers them CR-YYYY-NNN. GitHub Projects takes over scheduling and every PR must cite the CR number, which turns the board into a progress view the client can actually read. Figma carries before/after comparisons for visual changes, and after release Sentry watches for 48 hours.

# CR-2026-041 | Stackable coupons

- Requested by: Client / Manager Wang
- Channel: weekly call (2026-09-02)
- Verbatim request: "Could you also make coupons stackable?"
- Clarified scope: max 2 coupons per order
- Explicitly NOT included: tier bonuses, cross-store coupons, backfill
- Modules affected: Cart / Order / Refund / Report
- Data changes: orders gains coupon_stack_meta
- Test impact: 6 feature tests + refund regression
- Docs to update: spec/checkout.md, CHANGELOG.md
- Grade: B
- Estimate: 14 engineering hours
- Scheduled: Sprint 2026-W38
- Client approval: 2026-09-05, email reply "approved"

"Explicitly NOT included" is the most valuable field on the form: most disputes come from the slice the client assumed would be thrown in. Whoever writes the assessment clears this checklist:

☐ Does it alter table structure? Do we need a migration and a rollback script?
☐ Does it affect features already accepted? Which regression tests must be added?
☐ Does it touch payments, permissions or personal data?
☐ Is there a cheaper alternative we should offer alongside it?

What this costs us

It is slow. A Grade B ticket averages two to three working days from sentence to keyboard, and half of that is the client's own internal decision-making.
The admin time is unbilled. Each assessment takes 40 to 60 minutes that we do not charge for; ten tickets a month is eight hours of invisible cost.
Over-grading creep. Engineers are conservative and push Grade A items into Grade B, which makes the process feel rigid, so we audit grading decisions quarterly.

When this is the wrong process

Exploratory MVPs and proofs of concept. The spec is meant to grow as you build; three tickets a day would suffocate everyone. We switch to a fortnightly scope renegotiation.
Long-term maintenance retainers. Maintenance is a continuous stream of small requests, so we use a ticket pool with a monthly hour cap instead.

Why clients should care

Schedule: delays are rarely about technical difficulty; they happen because nobody remembers how much scope quietly got added. With a change log every delay has an origin: "three Grade B tickets totalling 31 hours landed in W36, so launch moves from Oct 1 to Oct 9."

Cost: you see the price before you nod, and no invoice appears after the work is already done.

Quality: every ticket has to answer "which tests, which documents," so six months from now whoever inherits the project reads a spec that matches the running code.

If you want to run this yourself

Agree the grading before designing the form. Plenty of teams start with a 20-field form that nobody fills in.
Keep written confirmation as light as possible. One word — "approved" — is enough; approval workflows just park the process in someone's admin department.
Put documentation write-back in the Definition of Done. No write-back, no closing the ticket. It is the only part of the system that compounds over years.

Where we have used it

A B2B industrial-parts quotation system accumulated 47 change requests over a six-month build: 31 Grade A (all inside the free allowance), 14 Grade B, 2 Grade C. One Grade C asked for multi-tier dealer pricing; the assessment showed it would rewrite the pricing data model at an estimated 62 hours, and the client deferred it to phase two.

On a restaurant-chain reservation app, by month three the client's operations lead was opening with "this is probably a Grade B, right?" — that is when the system was finally alive.

Frequently asked questions

If the client says it is urgent, does it still go through the whole process?

Urgent items take a compressed path: assessment and quote the same day, verbal approval is enough to start, but the ticket must be completed and confirmed by email within 24 hours. The process can be compressed; the record cannot be skipped.

What happens when the Grade A free allowance runs out?

Remaining small requests that month become quoted Grade B items, or the client defers them to next month's allowance. The allowance does not roll over or refund.

What if our own estimate is wrong and the hours blow up?

Estimating is our responsibility. If a ticket was quoted at 14 hours and takes 22, we absorb the difference with no retroactive charge.

Many people on the client side make requests. How do you avoid a flood?

At kickoff the client names one decision proxy: anyone can drop a request into #cr-inbox, but only that person can approve a Grade B or C ticket.

Work with us, or join us

If you are evaluating an external team for a Laravel or Flutter project and your past experience has been scope that keeps growing, invoices that keep arriving and nobody able to explain the delay, bring us the project and we will show you what a change request would look like in your situation. And if you are an engineer or PM who enjoys turning a vague sentence into something estimable and testable, we are hiring.