How do you separate bugs from scope changes after launch?
Most post-launch fights start with one bad label: “bug.”
A client says, “This doesn’t work.”
A builder hears, “Fix it for free.”
But “it doesn’t work” can mean:
- The product contradicts agreed behavior.
- The agreed work was never delivered.
- The customer now wants new behavior.
Only the first is a bug.
The other two are scope decisions.
When all three land in one ticket queue, someone ends up doing unpaid work.
How does your team separate them?
Really solid approach — I'm juggling something similar myself (building Xstream4K on the side), what's been the hardest part for you so far?
I think the classification becomes much easier when the original request and the delivered result stay together.
The messy cases I've seen are usually not “bug or feature?” in isolation. They're cases where the original client request is buried in Slack/email, someone remembers it differently, and three weeks later nobody has the same reference point.
Having the original request, the exact thing being discussed, and what was eventually changed in the same place makes that conversation much less subjective.
It also makes it easier to distinguish “we didn't deliver what was agreed” from “the client wants something different now.”
Useful rule: classify against an acceptance example before it reaches the backlog. Ask: “What exact user action and result were agreed?”
Attach the original acceptance note and a short screen recording to the classification so it feels like a shared decision, not a billing argument. A short post-launch warranty can cover documented defects; new behavior should always get its own estimate and approval.
That’s a very practical rule.
I like the shift from “Is this a bug?” to “What did both sides actually agree would happen?”
The acceptance sheet plus a short recording also makes the distinction verifiable, not just debatable.
For a delivery gap, do you treat it as a separate workflow from a bug, or do both follow the same remediation path?
I use separate lanes after a shared triage step. The evidence packet is the same: acceptance example, recording, and a reproduction check. A defect then gets an incident owner, severity, and remediation deadline; a delivery gap gets a completion plan and a fresh acceptance review. Both end with client confirmation, but separating them keeps a delivery miss from being treated like a blame issue.