Why Our Clean Review Missed Eleven Defects in the Invoice Loop

Eleven defects sat in the invoice-to-payment loop, and every one of them had passed the phase-by-phase checks. None of them threw an error.

What the passing checks were hiding

The platform could say an invite was on its way while no client received it. A client could accept an invitation and stay on the same page. The billing screen existed, but it never answered the only billing question that mattered, which was whether anyone had paid.

We had signed off on those checks as passing more than once before this walk-through. Our reasoning was the same each time: no error means it worked. Every client who reached the invite step hit the same silent failure, and we trusted the review precisely because it never complained.

The three failures are different, but they share a shape. Each phase looked complete from inside its own boundary. The email path had an instruction. The acceptance page had an action. Billing had a screen. The review only ever reported exceptions. It never reported progress through the workflow.

“No exception” is a statement about code behavior inside one phase. “The loop completed” is a statement about whether the client received the invitation, acted on it, and could see enough to know the payment state. Those two statements are not interchangeable, and we had been treating them as one. The loop’s name should have told us. Invoice to payment is a route across a client, an invitation, a page and a bill, and a phase check can only describe its own stop on that route.

Walking it as the client

The review changed when we walked the loop from the platform side and the client side. Defects showed up in the handoffs. Staff had been told the invite was on its way, and the client had no email. Accepting the invitation did not move the page. Billing did not expose payment state. Each one was plain the moment a person had to make the next decision.

That is how the count reached eleven. A review that waits for an exception can affirm every isolated action and still miss the handoff that makes the next action possible. The gap was a message that never arrived and a page that never changed. A linter would never catch that, and the phase-by-phase review passed clean while invitation, acceptance and payment all failed for the client.

What we fixed

Nine defects were fixed, six commits shipped, and the deployment was verified live. The second-package repair shows the shift best. It now adds a line to one itemised bill instead of creating a second subscription. The plan is also editable, which ends its add-only behavior.

That gives the loop a state that survives contact with a client. A second package belongs on one bill, and a plan that is editable can change after it exists. Both are behavior the client can use and staff can observe.

The work did not end cleanly. One migration still needed approval, one product question remained open, and the go-live gates were left standing. The record shows what was fixed more clearly than how those remaining decisions would resolve, and I would rather say that than pretend six live commits settled the whole workflow.

A review that reports no exception does not show a client can complete the journey. The check worth running walks the whole route as the client would, from the invitation arriving to the payment state being visible.

dxdev LESSON · paste into your AI coding agent
LESSON: No Exception Means the Code Ran, Not That the Journey Finished
SOURCE: dxdev.com/blog/exception-free-workflows-hide-broken-ux
WHAT HAPPENED: An invoice-to-payment loop was reviewed phase by phase (email step, acceptance page, billing screen), and each phase passed because it completed without throwing an error. In practice, the invitation email never sent for any client, accepting the invitation didn't advance the page, and the billing screen couldn't surface actual payment state, eleven client-facing defects total, none of which any phase-by-phase exception check could catch, because an exception check answers "did this phase's code run cleanly" and never asks "did the client actually get to the next step." The fix walked the loop end to end from both the platform and client sides, then shipped nine of the eleven fixes across six commits, verified live.
THE RULE: A phase-by-phase code review that only watches for exceptions can pass every phase individually while the end-to-end journey still fails at every handoff between phases, because a handoff failure (an email that silently doesn't send, a page that doesn't advance, a screen with no real state) produces no error for any single phase to catch; verifying a multi-step workflow requires walking it as a user would, checking what state persists across each handoff, not just that each step's code exits cleanly.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any multi-step customer workflow (invite, checkout, onboarding, billing) whose only test or review coverage is phase-by-phase / unit-level, with no end-to-end walk from the client's perspective checking state at each handoff.
  2. Any notification or messaging step (email, SMS, webhook) whose "sent" status is inferred from the calling code not throwing, rather than confirmed against actual delivery.
  3. Any status or summary screen presented to a client or staff member that can render successfully while showing no real information about the actual state it claims to represent (e.g., payment status, delivery status).
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.