Startup QA without a QA team

01The founder-time math nobody runs

Run the arithmetic you’d run for any other expense. Say you deploy daily and spend twenty minutes manually clicking through signup and checkout before each deploy. That’s roughly eighty hours a year of founder time doing what a script does in ninety seconds — but the hours aren’t even the real cost. The real cost is the deploys where you skip the check because you’re shipping from a cab, and one of those skipped checks is a broken checkout discovered by a customer.

The second hidden cost is velocity tax. When confidence is manual, engineers batch changes into riskier releases (“one deploy, fewer checks”), which makes every failure bigger and slower to bisect. Automation isn’t headcount substitution — it’s what lets a three-person team ship daily without holding their breath. The principles in our e2e best-practices guide apply at every company size; this post is about sequencing them when time is the scarcest resource.

02Find the money paths first

Draw your revenue graph as literally as you can on a whiteboard: anonymous visitor → signup → activation (the action that makes someone stay) → upgrade → renewal. Every edge where “broken” means “revenue lost” or “user churned” is a money path. For most SaaS that’s five edges or fewer: signup with email verification, login plus password reset, the core value action, checkout, and subscription changes or cancellation.

Everything else — settings pages, admin panels, nice-to-have filters — waits. Not forever, just until the money paths are guarded. Sequencing by blast radius rather than by ease-of-automation is the single highest-leverage decision in a small team’s test strategy.

03Automate the top five flows — nothing else yet

Write (or generate) one test per money path, end to end, against something that behaves like production. Two details make or break this at startup scale. First, synthetic data: every run gets its own identity so tests never collide — see test data rules that scale. Second, third-party safety: your checkout test must not hit live Stripe or a real mailbox. Stateful clones speak Stripe’s API, accept 4242…, and never move money — here’s how that works for cards, and the same pattern covers OTP email and SMS.

// e2e/money-paths.spec.ts — one guard per revenue edge
test('signup → upgrade', async ({ page }) => {
  const inbox = await clone.createMailbox();     // disposable, no real email
  await page.goto('/signup');
  await page.getByLabel('Work email').fill(inbox.address);
  await page.getByRole('button', { name: 'Create account' }).click();
  await inbox.waitForOtp();                      // verification code arrives via clone
  await completeOtp(page, inbox);

  await page.getByRole('button', { name: 'Upgrade to Pro' }).click();
  await fillCard(page, '4242 4242 4242 4242');   // clone card, no real charge
  await expect(page.getByTestId('plan-badge')).toHaveText('Pro');
});

Five tests like this cover the majority of catastrophic-regression surface. Resist the urge to build coverage breadth before you have depth on these five.

04Make them required checks

A suite that runs “when someone remembers” is documentation, not protection. Wire the money paths into CI on every pull request and mark them as required status checks so GitHub blocks merge on red — the exact setup is in required status checks as a merge gate, with the Playwright runner configuration in our GitHub Actions guide.

One policy matters more than tooling here: never disable a failing required check. If a test flakes, quarantine it behind a label with a deadline, then fix the cause — retries hide disease, they don’t cure it. Five reliable tests gating every merge beat fifty flaky ones everyone routes around.

05Schedule production checks

PR gates verify code before it ships. They say nothing about DNS, certificates, deploy configuration, environment variables, or a vendor API that changed shape overnight. That gap belongs to scheduled production checks: run the same two or three money-path tests hourly against your live site, alert into Slack on failure, and attach evidence so whoever is nearest can triage in minutes. The pattern is standard synthetic monitoring — we break down cadence, alerting, and ownership here.

Hourly is usually right at startup scale: fast enough to catch breakage before most customers do, cheap enough that nobody argues about the bill. If a check fails twice in a row, page; once, Slack.

06The lean stack, recapped

• Map the money paths. Signup, login, core action, checkout, plan changes. Nothing else yet.
• One hermetic test per path. Synthetic identities, cloned vendors, zero real side effects.
• Gate merges. Required checks on every PR; quarantine flakes, never delete gates.
• Guard production. Hourly checks on the same paths, alerts where your team actually lives.
• Expand only when it hurts. Add coverage after a bug escapes, targeting the class of bug, not the instance.

Revisit the founder-time math: eighty hours a year of manual checking becomes an afternoon of setup plus reviewing failures that actually matter. This loop — generate from plain English, gate PRs, monitor production — is exactly what Molar automates, and the free tier covers running it on a small app today.