Follow a Requirement
One sentence — "customers should be able to pause their subscription instead of cancelling" — traced from the planning meeting through the domain rule, the lifecycle, the contract, the code, the storage, the events, the tests, the migration and the telemetry.
Each step names what it decides, because a walk is only a walk if every stop narrows the options for the next one. The expensive part of this feature is not any single layer; it is that each layer inherits a decision from the one before it, so a wrong answer early is not a bug you fix later — it is a constraint every later layer has to work around. The step that quietly decides the most is the domain rule, and it is the one usually skipped because it produces nothing anybody can demo.
The sentence
In a planning meeting: "Customers should be able to pause their subscription instead of cancelling." Nobody objects, it is sized as small, and it goes into the sprint.
- — That the outcome is a subscription that survives — so this is a lifecycle change, not a cancel-and-resubscribe flow with better wording.
- — That the customer initiates it, which makes it a self-serve operation with the authorization and abuse questions that implies.
- — Nothing else yet. Everything below is still open, and the point of the next step is to keep it open long enough to ask what "paused" means.
- — The team starts at the UI. A "Pause" button is built that calls cancel and sets a reminder to resubscribe, and six months later nobody can explain why paused customers lost their discount.
- — The word "pause" is never defined, so support, billing and engineering each mean something different by it — the first bug report is an argument about intent, not about code.
- — It is sized as small because the UI is small. The estimate never includes the invoice, the proration, the reactivation or the migration of subscriptions already in flight.