What to Review Before Launching New Software

A pre-launch review doesn’t need to be heavy. It just needs to be honest.

The goal is simple: look at the product and ask where it’s most likely to fail once real users start relying on it. Then fix the worst problems before they happen.

Most teams skip this step because they are eager to ship. That’s understandable, but a few hours of review can prevent weeks of firefighting.

The five areas to check

1. Security

Security is the area where problems are most expensive and most embarrassing. A data breach or a compromised account can damage trust in ways that are very hard to recover from.

Before launch, check these basics:

• Authentication: Are passwords handled properly? Are sessions managed securely? Is there rate limiting on login attempts?
• Authorisation: Can users only see and do what they should? Are admin functions properly restricted?
• Secrets management: Are API keys, database passwords, and tokens stored safely? Are they in environment variables or a secrets manager, not in the code?
• Input handling: Does the product handle unexpected input safely? Can someone break things by entering unusual characters or very long strings?
• Dependencies: Are the libraries and packages up to date? Are there known vulnerabilities in any of them?

You don’t need a full penetration test for a first launch. But you do need someone to look at these basics honestly.

2. Privacy

If your product handles personal data — names, emails, payment details, health information, anything that identifies a person — you have legal obligations.

Before launch, make sure you can answer these questions:

• What personal data does the product collect, and why?
• Where is that data stored, and who has access to it?
• Is any data being sent to third-party services? If so, what are their privacy terms?
• Do you have a privacy notice that accurately describes what you do with data?
• Can users request their data or ask for it to be deleted?

This isn’t just a legal checkbox. If you can’t explain clearly what happens to someone’s data, the system isn’t ready.

3. Reliability

What happens when something goes wrong? In development, you can restart the server and try again. In production, real people are waiting.

Check these:

• Error handling: What does the user see when something fails? A helpful message, or a blank screen?
• Fallbacks: If a third-party service goes down, does your product handle it gracefully or crash?
• Timeouts: Are there sensible timeouts for external calls? A slow API response shouldn’t hang the whole application.
• Recovery: If the system goes down completely, how long does it take to get it running again? Has anyone actually tested this?

The goal isn’t perfection. It’s making sure the most likely failures are handled in a way that doesn’t make things worse.

4. Costs

Many teams launch without a clear picture of what the product will cost to run once real traffic arrives. This leads to unpleasant surprises in the first invoice.

Before launch, estimate:

• What will hosting cost at your expected usage level? What about at 2x or 5x that level?
• Which third-party services charge per request, per user, or per GB? How does that scale?
• Are there any usage-based costs that could spike unexpectedly — logging, storage, email delivery?
• Is the infrastructure set up efficiently, or are there obvious areas of waste?

You don’t need exact numbers. You need rough answers so that nothing is a complete surprise.

5. Support

Once the product is live, someone needs to look after it. The most common mistake is launching without answering the basic support questions:

• Who is responsible when something breaks?
• How will users report problems? Email, a form, a chat widget?
• What is the expected response time? Is that realistic given your team size?
• Who has the access and knowledge to investigate and fix issues?
• What happens if the person who built the system isn’t available?

If the answer to most of these is “we will figure it out later,” the product isn’t ready for users who are going to depend on it.

One simple test

Here is a quick way to check your readiness: can someone on the team explain the launch risks in plain language to a non-technical person?

If the answer is yes, you probably have a good understanding of what you are shipping. If the answer is no — if the risks are vague, or only one person really understands the setup — that’s a sign that more review is needed before launch.

How to do the review

You don’t need a formal process. Set aside a few hours. Go through the five areas above with the people who built the product. Write down what you find. Decide what must be fixed before launch, what can wait, and what needs watching.

If you want an outside perspective, a short review from someone who wasn’t involved in the build can be very valuable. They’ll see things the team has stopped noticing. Our launch audit is designed for exactly this — a structured review that covers security, cost, reliability, and support readiness.

Once you do launch, why launch is only the beginning covers what to expect in the first few months.

The point isn’t to delay launch. It’s to launch with your eyes open.