The Testing Pyramid: Recalibrated for Startups

The classic testing pyramid (many unit tests, fewer integration tests, few E2E tests) was designed for large systems where unit tests run fast and integration tests are expensive. For a startup monolith, the math is different.

Unit tests: for pure logic only. Unit tests are fast and cheap to write for functions with clear inputs and outputs: a pricing calculator, a date formatter, a validation function, a data transformation. For anything that involves databases, HTTP calls, or UI interactions, unit tests with mocks give you false confidence — the mock and the real thing will diverge.

Integration tests: your highest-ROI investment. Integration tests that exercise your actual database, actual API endpoints, and actual business logic are more valuable than any other test type for startup products. They catch the bugs that matter: a query that returns the wrong data, an API response that breaks the contract, a business rule that doesn't work with real data.

End-to-end (E2E) tests: the critical path only. E2E tests (Playwright, Cypress) are slow, brittle, and expensive to maintain. Pick 3–5 user journeys that absolutely cannot break — signup flow, payment flow, core product actions — and write E2E tests for those. Resist the temptation to cover everything.

What to Test First

Prioritize tests in order of consequence. Ask: "If this breaks in production and I don't notice for 24 hours, what happens?"

Priority 1 — Test these always:

• Authentication and authorization logic
• Payment processing and billing flows
• Data mutations that are hard or impossible to reverse
• Core product actions your users depend on daily

Priority 2 — Test when the logic is complex:

• Business logic with multiple conditions or edge cases
• Calculations (pricing, permissions, quotas, limits)
• Data transformation pipelines

Priority 3 — Test selectively:

• UI rendering and component behavior — test behavior, not implementation
• API contracts — test that responses match the expected shape

Skip for now:

• Trivial CRUD endpoints with no business logic
• UI styling and layout
• Third-party integrations you don't control (mock these minimally, test the real integration manually)

The Integration Test Setup That Works

For a Next.js + PostgreSQL application, a practical integration test setup looks like:

1. A test database — a separate database instance, or a schema per test run. Migrations run before tests, data is seeded, database is reset between test files.
2. A test HTTP client — Supertest (Node.js) or httpx (Python) that makes real HTTP calls to your server.
3. Test factories — functions that create valid test records. createUser(), createSubscription(), etc. Keeping these centralized means changes to your schema only require updating one place.
4. Minimal mocking — only mock things you genuinely can't control: third-party payment APIs, external email services, SMS gateways. Everything else should be real.

This setup runs slower than unit tests but catches 10× more real bugs.

The Coverage Trap

Test coverage percentages are a metric that looks good on dashboards and means almost nothing about actual quality. 90% test coverage achieved by testing getters and setters is less valuable than 30% coverage focused on critical business logic.

The question is not "how much is covered?" but "do the tests catch the bugs that would hurt users?" Review what your tests actually exercise when you write them. A test that proves a function returns a value is not the same as a test that proves the right value is returned under the conditions that matter.

A Practical First Month

• Week 1: Write integration tests for your authentication flows (login, signup, password reset, session expiry)
• Week 2: Write integration tests for your payment flows (subscription creation, upgrade, cancellation, failed payment)
• Week 3: Add Playwright E2E tests for your 3 most critical user journeys
• Week 4: Add unit tests for any business logic you've noticed being error-prone in code review

After month one, maintain the pattern: every time you fix a bug, write a test that would have caught it. This "bug-driven testing" approach builds a test suite that's perfectly calibrated to your actual failure modes.