There is a specific kind of quiet that happens right before a launch, when everyone agrees the thing is “basically done.” The demo went well. The feature works when you click through it. Someone suggests shipping it Friday.
That is usually the moment to slow down for an hour and ask six questions. They are not glamorous. None of them are about features. But they are the difference between a launch you forget about and one that pages someone at midnight.
We run this check on everything before it meets real users, whether it is an AI feature, an API, or a full platform.
1. Can we see what it is doing?
The first question is whether you would even know something was wrong. When a user reports a problem, can you find their request and see what happened, or are you reduced to guessing?
That means logs, metrics, and traces that land in one place you actually check. Not a server you have to SSH into and grep. Tools like OpenTelemetry make this less of a chore than it used to be, but the point is simpler than any tool: if it breaks at 9pm, the on-call person should be able to see why without waking up three other people.
2. What happens when something it depends on fails?
Everything your system calls will fail eventually. The database, the payment provider, the model API, the third-party service with the cheerful status page that is somehow always green. The question is not whether, it is what your system does when it happens.
Does the call time out, or does it hang forever and take the whole request with it? Does a failure retry sensibly, or hammer a struggling service until it falls over completely? Is there a fallback, even a plain “try again in a moment” message, instead of a stack trace? Reliability is mostly about behaving well when other things behave badly.
3. Is it actually secure?
Not a full audit, just the basics that get skipped under deadline pressure. Are secrets out of the codebase and out of the repo history. Does each part have only the access it needs, rather than admin keys passed around for convenience. Is user input validated before it reaches a database or a model. Are the obvious headers in place.
Most breaches we read about are not clever. They are a leaked key or an input nobody checked. Closing the easy doors handles most of the risk.
4. Do we know what it costs?
This one catches AI features especially hard. A feature can work beautifully and still be quietly unaffordable. Before launch, you want a rough cost per request and an honest answer to one question: as usage grows, does this scale in the right direction.
If the cost per user goes up as you add users, you have a problem that success will only make worse. Better to find that with ten users than ten thousand.
5. Does it stay fast under real load?
A system that is quick for one person clicking around can fall apart when a hundred people show up at once. The demo never reveals this, because the demo is one person on a good connection.
So you put it under something resembling real traffic before launch and watch what happens. Where does it slow down. What gives out first. It is fine to have limits. It is not fine to discover them from your users on day one.
6. If the next release is bad, can we undo it fast?
You will ship a broken release at some point. Everyone does. What matters is how long it takes to get back to safety.
Can you roll back in minutes, or does it mean a tense manual restore. Can you undo without losing data that came in between. If a deploy goes wrong, is the answer “click revert” or “cancel everyone’s evening.” A clean rollback path is the seatbelt of shipping software. You hope not to use it, and you really want it there.
Using the check
You do not need all six to be perfect. You need to have asked each one honestly and made a deliberate call. “We know performance is untested and we accept that for a soft launch to fifty users” is a fine answer. “We never thought about it” is not.
The whole thing takes about an hour, and it has saved us more bad weekends than any other habit. If any answer is a genuine no, the system is not ready, however good the demo looked.
If you are about to ship something and want a clear-eyed second pass before it goes live, we are happy to run this with you. See how we work across software engineering and cloud and DevOps, or book a scoping call.