Testable always, tested sometimes

One distinction has to come first, because the rest falls apart without it. Writing testable code and writing tests are two different decisions. Code with its side effects pushed to the edges and its dependencies injected is easier to understand, change, and debug whether or not a single test exists, and it costs almost nothing once the patterns are habit. My book goes into this at length under the heading "testable, not tested"; I will not re-make that case here.

So write testable code from day one, always. Then decide, separately and by stage, how many tests that testable code actually warrants. Here is the dial I use.

The dial

Before product market fit, while you are still experimenting: close to zero tests, on purpose. The code is testable but untested. You are going to throw most of it away, and writing comprehensive tests for code you will delete is waste, with the added cost I opened with: tests make disposable code feel permanent exactly when you most need it to feel disposable.

As you approach product market fit: test the things you cannot hold in your head. A gnarly pricing calculation, an awkward state machine, the one piece of logic you are genuinely unsure about. Not the CRUD around it. The test you write here earns its place by checking something you could not verify by reading.

Once you have hit product market fit: test the core that must not break. The calculus has flipped. You are no longer speculating on whether this code should exist; you are protecting an investment you have proven. Because you kept the code testable the whole time, adding the tests now is cheap, and you add them where a failure would actually hurt the business.

As the team scales: lean into regression coverage. The risk has changed shape again. Early on the danger was that you broke your own code, and you knew where the bodies were. Now the danger is that someone who has never seen this code, and never will until they touch it, breaks it without realising. Tests are how you let strangers change code safely. That is most of what a large test suite is actually for, and it is close to worthless at the experiment stage because there are no strangers yet.

The pattern underneath is simple. A test grows more valuable as the code stabilises, so it is less likely to be thrown away, and as more people who do not understand it gain the ability to break it. Before product market fit both are low, so the right number is near zero. At scale both are high, so you invest.

And I do not say "write fewer tests" lightly: I co-founded a company that sold software quality for a living, and I have argued you should not even run quality assurance as a separate activity. The point was never to test less because testing is bad. It is to spend testing effort where the stage makes it pay.

The two overrides

Two things cut across the dial, and you apply them regardless of stage.

The first is complexity you cannot reason about. If you cannot convince yourself a piece of logic is correct by reading it, test it, even in an experiment, because the test is doing your thinking for you, not protecting an investment.

The second is irreversibility. Anything where a single failure is catastrophic, money moving the wrong way, data you cannot get back, gets tested from the first line, no matter how early you are. Stage sets the default. Danger overrides it.

Summary

Write testable code always; write tests by stage. Before product market fit, test almost nothing and keep your experiments cheap to kill. As you close in, test the logic you cannot hold in your head. Once you have found fit, protect the core, and as the team grows, invest in the regression coverage that lets people change code they do not know. Override the dial only for logic you cannot reason about and failures you cannot undo. This is about when to invest in tests; for how to test the code once you decide to, the book goes deeper.