A Refund Page That Only Handles Full Orders: 200 Complaints in 3 Days
Business logic bugs sail past every automated guardrail, so a frontend who doesn't understand the domain ships a workflow that looks correct but loses money and trust. The fixes here are cheap and team-level: ask business questions at requirement review, write comments that carry the why, and test by scenario so a PM can see missing branches.
A refund page in production had zero technical defects: Sentry logged nothing, Jest gave 100% code coverage, code review passed, and the UI behaved exactly as written. The only problem was that the written behavior didn't match the business. The engineer modeled refunds as "user clicks refund, API returns entire order, done", and never once asked whether a customer might return just one item, whether shipping gets refunded, or how already-used coupons split. The PRD did mention partial refunds, but the note sat collapsed in a comment field, so every automated check and human review validated the same wrong assumption.
The incident took two days to diagnose and ended with 200+ support tickets. It illustrates why business logic errors are more dangerous than technical crashes: TypeErrors get caught by error boundaries and code review, but a wrong refund model is invisible to ESLint, TypeScript, and unit tests unless the test cases themselves encode the right business scenarios. The team now forces frontend devs to bring at least three business questions to requirement review, writes business comments that explain why a formula exists and who confirmed it, and organizes tests by business scenario rather than code branch so product managers can spot missing branches during review.
A PRD that hides a critical rule like partial refunds in a collapsed field turns a business requirement into a lottery draw; the process, not the engineer's knowledge, is the first failure point.
100% code coverage on tests that encode the same wrong assumption converts a business blind spot into a green signal that every reviewer trusts; the coverage number measures internal consistency, not match to actual refund rules.
The salary-ceiling claim is a strong assertion from one team's experience; it explains the refund incident neatly, but no evidence is offered that it generalizes across roles or companies.
The full-order-only refund bug stems from a broken requirements and QA pipeline, not a frontend oversight. Partial refunds never surfaced in product briefs, test cases, or acceptance, yet the entire blame lands on the frontend engineer. The same defect appeared in another app a year earlier, suggesting a systemic blind spot across the industry. Some comments also point out that frontend developers are routinely shut out of requirement reviews, so they never operate with enough business context to catch such gaps.
How can this be blamed on the frontend missing it? Clearly, aside from the product manager, nobody knew about partial refunds. The product manager probably misses things often, and developers are too lazy to even bring it up. Something this obvious, and it still gets missed?
First, the product's business requirements weren't clear, and no step in the entire development process raised any objection. The whole scapegoat is put on the frontend alone.
1. Didn't the product review mention partial refunds? 2. Didn't test cases cover partial refunds? 3. During acceptance, didn't the product verify its own partial refund requirement? 4. Did the backend even implement partial refunds?
Indeed
The frontend missed it.