Most seed-stage teams have either no tests or the wrong twenty. Very few have the right five.

“We will add tests later” almost always means never. “We must have full coverage before we ship” almost always means the team burns two sprints writing tests for pure utility functions while the two code paths that actually matter, billing and auth, remain untested.

The gap between those two failure modes is a small, disciplined set of tests that pay for themselves within a month. Five of them.

Why “Just Add Tests” Advice Fails

The generic advice about testing was written for teams with a mature codebase, a QA function, and a release manager. Seed-stage teams have none of those. They have three engineers, a deploy pipeline that runs on a laptop, and every hour of engineering time is contested by product, sales, and the investor deck.

In that environment, “we should have good test coverage” is not actionable. Coverage-thinking asks the wrong question, which is “what percentage of our lines are exercised.” The right question is “which failure modes would ruin our week if they shipped tomorrow, and how do we make each of them impossible.”

You do not need many tests to answer that question. You need the right ones.

The Five Tests That Actually Matter First

These are ordered roughly by how much pain they prevent per hour of effort to build. Start at the top and stop when you run out of runway for the week. Even the first two put a team ahead of most seed-stage codebases I have seen.

1. A smoke test on the golden path. One user, one full flow, run on every commit. Sign up, do the main thing your product does, log out. Should complete in under a minute. This is not a coverage tool. It is the “did we ship a working build” check. Nine times out of ten, when a seed-stage deploy takes down production, this one test would have caught it before the deploy button was pressed.

2. Money-and-auth tests. Two categories where a bug is not just a bug, it is a business ender. Every function that touches billing, credits, subscriptions, or session identity gets a test. Customers forgive most bugs. They do not forgive being charged wrong, being charged twice, or seeing another user’s data. These are the tests where “we didn’t have time” is not a defensible sentence to say out loud.

3. Contract tests for external services. Not the service itself. The assumption you are making about the shape of what they return. Stripe, Twilio, OpenAI, your auth provider. When they change their response shape (they will, quietly, in a minor version bump), you find out from a red test the morning you deploy, not from a customer at 11pm. Record a real response, assert on the fields you actually read, run the test on every commit.

4. Migration tests on a real database. Every schema change gets a test that both applies the migration and rolls it back cleanly, on a real database, not a mock. This is the category where I have seen the most seed-stage disasters. Migrations pass locally because the local database is empty or has ten rows. They destroy production because one column has NULLs the dev database did not, or a foreign key implies a row that does not exist, or a rename cascades to a view nobody remembered was there.

5. The three-line replay for every production bug. Before you fix it, write a test that reproduces it. Three lines is often enough. Set up the state that caused it, call the code path, assert on the wrong behavior. Then fix. This one is the compounder. Every bug you have already had becomes a bug you cannot ship again. Over a year, this accumulation is the single largest safety net your codebase will have.

What NOT to Build First

The tests I actively tell seed-stage teams to defer, sometimes by six months:

  • Unit tests on every pure function. Pure functions are the least likely code to break. Coverage on them looks impressive and prevents almost nothing.
  • End-to-end tests for every user flow. Slow, brittle, expensive to maintain. One golden-path smoke test is worth ten of these at seed stage.
  • Snapshot tests for UI components. They mostly catch design changes you made on purpose, then require updating. Net negative until the product design is more stable.
  • Load and chaos tests. Real problems, not seed-stage problems. Add them after your infrastructure is worth defending.
  • 100% coverage as a target. Coverage is a metric that is easy to game and disconnected from whether the tests catch the failures that matter. Optimize for “would this test have prevented a real incident.”

 

The rule underneath all five deferrals is the same. At seed stage, the cost of a test is not writing it once, it is maintaining it every time the code around it changes. Which is often. So the tests that survive are the ones tied to a business-ending failure mode, not to a code-coverage target.

The Diagnostic Question

Before adding any test, ask one question. If a customer reports a critical bug at 5pm, can we ship a verified fix by end of day, confident we have not broken something else?

If the answer is yes, your test suite is doing its job. Keep the five, add more sparingly.

If the answer is no, the missing piece is almost never “more tests.” It is one of the five above. The team can ship at 5pm because there is a smoke test that catches basic breakage, a money-and-auth test that catches the categories that matter most, and a replay test for the specific bug they just fixed. Everything else is either overhead or optional.

What Changes Once You Have These

The shift I watch happen when a team gets these five in place is not “we ship faster.” It is “we ship on Fridays.” Confidence in the test suite means the team stops treating every deploy as a potential incident. The bar for touching production comes down. The release cadence goes up. Bugs that would have taken half a day to isolate get caught in the pipeline with a stack trace pointing at the exact line.

None of that requires 90% coverage. It requires the right 20%.

Let’s Talk

If your team is either shipping without tests and starting to feel the drag, or you have tests but the ones you have do not seem to catch the incidents that actually happen, the fix is usually rearranging what gets tested, not writing more of it. Happy to walk through where your five would go, no pitch, just a working session. Reach out.