Quality Gates

Software development has two schools of thought about quality.

Fail-safe tries to prevent every issue. More tests, more checks, more approval gates. In some domains this makes sense — banking, medical devices, regulated industries. When regulations force the hand, comply.

Safe-to-fail acknowledges reality. Bugs will happen. No amount of testing catches every issue before it reaches production.

Pick safe-to-fail.

Instead of preventing every bug, focus on how quickly the developer can detect, fix, and recover. This is where the other principles earn their keep. Monitor from day one. Deploy small chunks often. Use feature flags to roll back instantly. The safety net isn't a test suite — it's the ability to respond.

About tests specifically: it depends on the project. Sometimes there's a dedicated tester. Sometimes the developer writes unit and integration tests. Sometimes it's deploy-and-pray — check it in production.

In Varstatt, here's a strong opinion: using TypeScript correctly can replace the majority of unit tests otherwise written for data validation and type safety. When data structures are enforced at compile time, entire categories of bugs disappear before anything runs.

Sometimes the developer deliberately skips TypeScript to allow flexibility in data. In those cases, don't assume data will be there as expected — handle the absence gracefully instead of crashing.

"Test adequately for the risk level" means exactly what it says. A payment flow gets more scrutiny than a settings page. A user-facing feature gets more attention than an admin tool. Match effort to the stakes.

The goal isn't zero bugs. It's zero surprises that can't be recovered from in minutes.