What counts as a critical flow?

Every team we work with has a list of things that “should be tested”. It’s usually long, and it usually starts with whatever broke last month. That’s a reasonable instinct, but it isn’t a way to decide where automation pays off.

We use a shorter question: if this flow fails silently for a day, what does it cost you?

Three tests for a critical flow

A flow is critical when at least one of these is true:

• It touches money. Checkout, upgrades, payouts, refunds.
• It’s a door. Signup, login, password reset, invitations. If it fails, nobody gets in to notice anything else.
• It involves more than one person. Sharing, permissions, real-time edits. These break in ways a single developer rarely reproduces.

A small suite that runs on every pull request beats a large one nobody waits for.

What it looks like in code

A critical-flow test reads like the user’s goal, not like a list of clicks:

// checkout.spec.ts
test('customer can pay with a promo code', async ({ page }) => {
  await signInAs(page, 'customer');
  await addToCart(page, 'Pro plan');
  await applyPromo(page, 'LAUNCH20');
  await pay(page);
  await expect(page.getByRole('heading')).toHaveText('Order confirmed');
});

Helpers like signInAs() hide the details so the test survives UI changes.

How many is enough?

For most startups, the answer lands between 6 and 12 flows. Below that you’re missing a door; above that you’re drifting into regression testing, which is a different job with a different budget.