Solo Dev E2E Testing: 5 Smoke Tests That Prevent Customer-Facing Bugs

1. The Cost of Skipping E2E Tests

Solo devs ship fast. That's the whole advantage. But speed creates a specific failure mode: you push a deploy, something breaks in the signup or checkout flow, and you don't find out until a customer tells you. Or worse, you find out from the absence of signups and spend two days debugging why growth flatlined.

The instinct is reasonable. E2E tests feel like a big-team thing. Selenium grids, test environments, QA engineers with Jira boards. That version of testing is overkill for a solo dev. But the minimal version, five smoke tests covering your revenue-critical flows, is not. It takes an afternoon to set up and pays for itself the first time it catches a broken deploy.

The math is simple: one lost customer because of a broken signup flow costs more than the 3 hours it takes to set up basic smoke tests. For a SaaS charging $50/month, losing even one customer to a preventable bug means you've lost $600/year in LTV. Five customers and that's $3,000, more than enough to justify an afternoon of test setup.

2. The 5 Smoke Tests That Actually Matter

You do not need 200 tests. You need five that cover the flows making you money. Here they are, in order of priority:

1. Signup flow. Navigate to your signup page, fill in the form, submit, verify the user lands on the dashboard or welcome screen. This is your acquisition funnel. If it breaks, new revenue stops.

2. Login flow. Log in with valid credentials, verify access to the authenticated area. If login breaks, every existing customer is locked out.

3. Core action.Whatever your app does, test the main thing. If you're a project management tool, create a task. If you're a CRM, add a contact. If you're an invoicing app, generate an invoice. This is why people pay you.

4. Checkout/payment.If you have a payment flow, test it end to end with Stripe's test mode or your payment provider's sandbox. A broken checkout page is silent revenue loss.

5. Critical settings. Test that users can update their email, password, or whatever settings would cause a support ticket if broken. This one prevents the angry emails that distract you from building.

3. Setting Up Playwright in 30 Minutes

Playwright is the best choice for solo devs because it's free, fast, and works across all browsers. The setup is three commands:

That gives you a working Playwright config, a tests directory, and the browser binaries. Your first test file goes in tests/smoke.spec.ts and looks something like this:

test('signup flow works', async ({ page }) => {
  await page.goto('/signup');
  await page.fill('[name="email"]', 'test@example.com');
  await page.fill('[name="password"]', 'TestPass123!');
  await page.click('button[type="submit"]');
  await expect(page).toHaveURL(/dashboard/);
});

Each smoke test follows the same pattern: go to the page, interact with the form, verify the outcome. You can write all five in under an hour. Run them with npx playwright testand you'll see results in seconds, not minutes.

The key insight for solo devs: you do not need page objects, fixtures, or any abstraction layer. Write the tests as flat scripts. You can refactor later if you ever reach 50+ tests. For five smoke tests, simplicity wins.

4. Wiring Tests Into CI

Tests that run locally are useful. Tests that block bad deploys are essential. The real unlock is wiring your smoke tests into CI so they run on every push. A failing test blocks the deploy. You stop finding out about bugs from angry users and start finding out from a red build.

On GitHub Actions, the setup is a single YAML file. Vercel, Netlify, and Railway all support pre-deploy checks. The pattern is the same: spin up your app in the CI environment, run the smoke tests against it, fail the build if any test fails.

# .github/workflows/test.yml
name: Smoke Tests
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npm run build && npm start &
      - run: npx playwright test

This adds maybe 2 to 3 minutes to your CI pipeline. In exchange, you never deploy a broken signup flow again. For a solo dev, this is the highest-leverage 20 minutes you can spend on infrastructure.

5. What E2E Tests Catch That Unit Tests Miss

Unit tests verify logic. E2E tests verify experience. There's a whole category of bugs that only show up when real components render in a real browser: a layout change pushing a submit button offscreen, a form that validates client-side but never sends the POST request, a redirect loop after OAuth, a modal that blocks the page but has no close button.

These are the bugs that churn users because they make your app feel broken even when the backend logic is correct. Unit tests will never catch them because unit tests never load the actual app. They test functions in isolation, which is valuable for logic bugs but blind to integration bugs.

The sweet spot for a solo dev is unit tests for complex business logic plus E2E smoke tests for critical user flows. You do not need to choose one or the other. They catch different categories of failure and the combination gives you confidence that your deploys are safe.

6. Auto-Generating Tests From Your App

Writing tests manually works for five smoke tests. But if you want broader coverage without spending days writing Playwright scripts, tools exist that auto-discover test scenarios by crawling your app. They identify forms, buttons, navigation paths, and critical flows, then generate standard Playwright test files you can run, inspect, and modify.

The key thing to look for is output format. If the tool generates proprietary YAML or requires a cloud runtime, you're trading one dependency for another. The best approach is a tool that outputs standard Playwright .spec.ts files you can commit to your repo and run in any CI pipeline. That way, if you ever stop using the tool, your tests still work.

For solo devs, auto-generation is the difference between "I should write tests but I don't have time" and actually having test coverage. The setup is typically a single command pointed at your staging URL, and the result is a set of test files covering every discoverable flow in your app.