My tool found sixteen critical problems. Twelve were wrong.

The first time I ran Launch Triage against Brik, it found sixteen critical problems.

Twelve of them were wrong.

Launch Triage is a small tool I built to inspect a software project before release. It looks for the mistakes that are easy to miss when a team is rushing towards launch: exposed secrets, unsafe settings, incomplete release controls, and other problems that can turn an ordinary deployment into a bad day.

It runs on the developer’s computer or inside the checks attached to a code repository. It does not execute the product or upload its source code anywhere. The promise is straightforward: point it at a project and get a short report of what deserves attention before the product goes live.

Sixteen critical findings did not feel like a short report. It felt like a fire alarm going off in every room.

I opened each finding and traced it back to the file that caused it. The tool had counted some problems more than once because it was reading a hidden copy of the same work. It treated database change files as though they were ordinary application code. It misunderstood a few protected pages. It also raised an alarm about the state of the project even when that state was expected.

Every one of those findings had a reason. The rules were doing exactly what I had written them to do. The problem was that the rules did not understand enough of the situation around the files they were reading.

That distinction matters when software is making a judgement for someone else. A false alarm still costs time. It sends a developer into the wrong file. It makes a founder believe a release is less ready than it is. Most importantly, it makes the reader less likely to trust the next warning.

A developer who sees sixteen critical findings and discovers that twelve are wrong will stop listening before reaching the four that deserve attention.

I changed the rules and ran the same project again. The updated scan returned two critical findings, both real. Then I ran it against a separate project that contained a settings backup which should never have been committed. The tool still caught it.

That second check was as important as removing the false alarms. It is easy to make a scanner look more accurate by making it quieter. If the quieter version also misses the dangerous thing, nothing has improved. I needed fewer alarms without weakening the one alarm that mattered.

The tool then had to survive its own release process.

Version 1.2.0 failed before it reached the public package registry. A command used during the release had changed the shape of its answer. My test expected a list. The newer version of the command returned the same information as an object organised by package name.

The release stopped.

That was inconvenient, but it was the correct result. The check existed to prevent a broken package from being published, and it had done exactly that. I updated the test to accept both valid forms, fixed the command version used by the release, and published version 1.2.1. The public release then passed a real workflow using the same version other people would install.

These two failures taught me different things.

The first showed that a warning system can be technically correct and practically unhelpful. The second showed that a useful gate sometimes proves its value by refusing to let your own work through.

The difference is evidence. A warning earns trust when a person can trace it to something real. A release gate earns trust when it stops the bad release and allows the corrected one. A long report, a red badge, or a confident score does not create that trust by itself.

This is especially important now that more teams are using AI to review work, summarise risks, and recommend decisions. Speed makes a weak judgement arrive faster. It does not make the judgement better. If the person reading the result cannot see why it was reached, test it against a known case, and correct it without making the system blind, the report becomes another opinion with better formatting.

Launch Triage is public now, with its failed release still visible beside the corrected one. I kept the failure because it is part of the evidence. The tool is more useful because it was wrong in a way I could measure, and because the process around it refused to hide the next mistake.

If your product is close to release and the important checks still depend on memory, I offer a focused Launch Rescue that turns one fragile journey into a tested release candidate.