My tool found sixteen critical problems. Twelve were wrong.

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

Twelve of them were wrong.

Launch Triage is a small tool I built to check a software project before it’s released. It looks for the mistakes that are easy to miss when a team is rushing to launch: passwords and keys left in the code, unsafe settings, missing release checks, and other things that can turn a normal release into a bad day.

It runs on the developer’s own computer or in the automatic checks attached to a code repository. It doesn’t run the product or upload the code anywhere. The idea is simple: point it at a project and get a short list of what needs attention before you go live.

Sixteen critical findings didn’t feel like a short list. It felt like the fire alarm going off in every room.

I opened each one and traced it back to the file behind it. The tool had counted some problems twice because it was reading a hidden copy of the same work. It treated database change files like normal application code. It misread a few protected pages. And it complained about the state of the project even when that state was expected.

Each of those findings had a reason. The rules were doing exactly what I’d written them to do. They just didn’t understand enough about what was around the files they were reading.

That matters when software is making a judgement for someone else. A false alarm still costs time. It sends a developer to the wrong file. It makes a founder think a release is less ready than it is. Worst of all, it makes people less likely to believe the next warning.

A developer who sees sixteen critical findings and finds out twelve are wrong will stop listening before getting to the four that matter.

I changed the rules and ran it on the same project again. This time it found two critical problems, both real. Then I ran it on a separate project that had a settings backup that should never have been saved in the code. It still caught that.

That second check was as important as getting rid of the false alarms. It’s easy to make a scanner look more accurate by making it quieter. If the quieter version also misses the dangerous thing, you haven’t improved anything. I needed fewer alarms without losing the one that mattered.

Then the tool had to get through its own release process.

Version 1.2.0 failed before it reached the public package store. A command used during the release had changed the format of what it returned. My test expected a list. The newer version of the command returned the same information grouped by package name instead.

The release stopped.

That was annoying, but it was the right result. The check was there to stop a broken package being published, and that’s what it did. I updated the test to accept both formats, pinned the command version the release uses, and published version 1.2.1. That release then went through a real workflow using the same version other people would install.

The two failures taught me different things.

The first showed that a warning system can be technically right and still not help anyone. The second showed that a good check sometimes proves itself by refusing to let your own work through.

What makes the difference is evidence. People trust a warning when they can trace it to something real. They trust a release check when it stops the bad release and lets the fixed one through. A long report, a red badge or a confident score doesn’t earn that trust on its own.

This matters more now that more teams use AI to review work, summarise risks and recommend decisions. Speed just gets a weak judgement to you faster. If the person reading the result can’t see why it was reached, test it against a case they know, and correct it without making the system blind, the report is just another opinion with nicer formatting.

Launch Triage is public now, with the failed release still showing next to the fixed one. I left the failure there because it’s part of the evidence. The tool is more useful because it was wrong in a way I could measure, and because the release process didn’t let the next mistake slip through.

If you want to run it on your own project, it’s one line:

npx launch-triage .

It’s free and MIT licensed. It reads your code and writes a report on your own machine, and it never uploads anything. Treat what it says the way I do now: open every flagged file before you believe it, and remember that no findings means nothing matched, not that there’s nothing wrong.

If your product is close to release and the important checks still depend on someone remembering them, I offer a focused Launch Rescue that turns one fragile part of your product into something tested and ready to release.