The Real Cost of Skipping Automated Tests

Nobody removes tests from a proposal because they think testing is worthless. They remove them because the number needs to come down and tests look like the one line item with no visible output. We understand the pressure. We also inherit the result often enough to describe what happens next with some precision.

Month one to four feel fine

Early on, one or two developers hold the whole system in their heads. Changes are quick, bugs get caught by hand, and the decision looks vindicated. This period is genuinely pleasant and completely misleading.

Month five is when it turns

The codebase passes the point where anyone holds all of it. Now every change carries a question nobody can answer cheaply: what else touched this? Manual regression testing appears, informally at first, then as a scheduled activity that quietly consumes days per release.

Month nine is the freeze

We have seen this shape many times. The team starts routing around the risky module rather than modifying it. Features get built in awkward places because the sensible place is too dangerous to touch. Velocity does not collapse dramatically — it erodes, which is far harder to argue about in a status meeting.

A test suite is not insurance against bugs. It is permission to change things.

What we actually write

We are not chasing a coverage percentage. Our default is feature tests over the paths that carry money or data integrity, unit tests on genuinely tricky logic, and nothing at all on framework glue. That is typically fifteen to twenty percent of build effort and it is the part of the budget we defend hardest, because it is what lets year two cost less than year one instead of more.