The Startup Testing Strategy: Maximum Confidence, Minimum Tests

The textbook says unit tests for every function, integration tests for every module boundary, and E2E tests for every user flow. That is great advice for a team of fifty with dedicated QA engineers. It is terrible advice for a startup with two developers and a six-week runway to prove product-market fit.

But the opposite extreme is equally bad. We have taken over codebases with zero tests where the team was afraid to change anything. Every modification was a deployment-and-pray exercise. Bug reports from users were the testing strategy.

Our approach: maximum confidence testing. Write the fewest tests that give you the most confidence. We aim for eighty-five percent confidence with roughly twenty percent of the testing effort.

Tier one (highest priority): E2E tests for critical paths. These come first, not last. Identify the three to five workflows that represent the core value of the application. For SaaS: sign up, complete onboarding, perform the primary action. Write Playwright tests for each happy path with basic validation. Eight to fifteen tests, about four hours to write. These catch the most damaging bugs and integration issues between frontend and backend that unit tests simply cannot catch.

Tier two: unit tests for business logic. The service layer functions that calculate prices, determine eligibility, apply discounts, and make decisions. Our heuristic: if a function has an if statement implementing a business rule, it gets a unit test. If it just passes data through, skip it. Twenty to forty tests, three to five hours to write. These run in milliseconds and catch logic regressions.

Tier three: integration tests for data access. Test repositories against real PostgreSQL via Docker. Focus on complex queries -- anything with joins, aggregations, or subqueries. Skip simple CRUD operations. Ten to twenty tests, two to three hours.

Full suite for a startup application: fifty to seventy-five tests. Ten to fifteen hours total writing time. Runs under sixty seconds for unit tests, under three minutes for the full suite including E2E and integration.

What we deliberately skip: snapshot tests (brittle and low-value), component rendering tests (E2E covers visible behavior), mocked API tests (test the real API instead), and hundred percent coverage targets (diminishing returns past seventy percent).

The non-negotiable rule: tests must run in CI on every PR. Tests that only run locally are tests that stop running within a month. If CI takes over five minutes, we optimize or remove the slow tests. A slow test suite is a skipped test suite.