Give the Revenue Path Its Own Test Suite

Every application has one path that matters more than the others.

For a commerce app it is checkout. For a SaaS product it is signup and activation. For a service business it is the walk from a visitor landing on a page to a qualified, attributed enquiry actually stored in the database.

Most codebases test that path to exactly the same standard as the settings page. That is the mistake.

Quiet failure is the expensive kind

A crash is cheap. Something pages you, someone fixes it, you lose an hour.

The expensive failure is quiet. The form still submits. It still shows a success state. The row never lands, or it lands without its attribution, or a rate limiter that was meant to stop bots starts silently eating real submissions.

Nothing is red. Nobody is paged. You find out weeks later, from a number that is lower than it should be, and by then you cannot tell which deploy did it.

That is not a bug you find with more coverage. It is a bug you find by deciding, in advance, which path is not allowed to break.

Naming it changes how it gets treated

On the event platform I am building, the revenue-critical flow is called the money path. It is a named concept in the codebase, and it has:

• its own Vitest suite (money-path.test.ts),
• its own end-to-end script that runs against a real production build,
• a separate verify:e2e command that exercises it in a browser.

The naming is not decoration. An unnamed critical flow gets tested like ordinary code, because nothing tells the next person it is different. A named one is something a reviewer can ask about and a test can defend.

Alongside it, the suites that protect it: attribution, validation, security, drafts, venue gating. Six files, 106 cases — every one runnable by anyone who clones the repository.

One command decides

pnpm verify      # typecheck + lint + test + production build
pnpm verify:e2e  # money path in a browser, then page contract, then perf budget

pnpm verify is the gate. Not four commands a contributor is trusted to remember — one, which either passes or does not.

Two details in there matter more than they look:

The build runs without a database. CI should be able to prove the application compiles and renders without provisioning Postgres for every run. Database-dependent behaviour moves into the e2e lane, where it belongs, and the fast gate stays fast.

Rate-limit state is cleared before e2e runs. The e2e script deletes the rate limit buckets first. Without that, the suite passes or fails depending on what ran before it — and a test that depends on execution order is worse than no test, because it teaches the team to ignore red.

Budgets that fail, not budgets that report

Two scripts run alongside the tests:

• a page contract check, asserting the pages that matter still contain the structure they are supposed to,
• a performance budget, which fails when a page exceeds its weight allowance.

A performance report that nobody opens changes nothing. A performance budget that fails a command changes what gets merged. Same data, completely different outcome — the only difference is whether it can say no.

Write down what is pinned and why

TypeScript is pinned to 5.9 and ESLint to 9 in that project, for real toolchain reasons, and the reason is recorded as a numbered decision in docs/DECISIONS.md — nineteen of them so far.

An unexplained pin has a short life. The next person sees an available upgrade, takes it, and the build breaks in a way that takes an afternoon to trace back. A recorded reason survives the person who made it, which is the entire point of writing it down.

The short version

• Identify the one path that carries the money. Name it in the codebase.
• Give it its own suite and its own end-to-end check against a real build.
• Make the gate a single command, so passing is unambiguous.
• Make budgets fail rather than report.
• Record why a constraint exists, or it will be removed by someone acting reasonably.

None of this is exotic. It is mostly deciding, before you need it, which failure you are not willing to find out about from a slow month.