Technical Due Diligence Before You Launch

Find launch risk while choices are still reversible

A due-diligence review is not a hunt for elegant code. It is a structured look at whether the product can be released, operated, changed, and recovered by the people who will own it.

Questions to answer

• Can a new team run the project locally and deploy it using documented steps?
• Are production accounts, environment configuration, domains, and vendor dependencies owned by the right organization?
• What data is stored, who can access it, and what happens when a request fails or is repeated?
• Are backups, error reporting, logs, security updates, and recovery steps proportionate to the product’s risk?
• Which core user journeys have been tested on the target devices and browsers?
• What is unfinished, fragile, or expensive to change, and what should be addressed before launch?

End with decisions

The useful output is a short risk register with impact, likelihood, evidence, recommendation, and owner. Separate launch blockers from follow-up improvements so a review creates momentum rather than an endless refactor.

Review in the order decisions depend on

1. Confirm you can operate it

   Start with access, local setup, deployment, environment configuration, logs, backups, and recovery. If nobody can safely operate the product, code quality is not the first launch decision.

2. Trace the highest-risk data

   Follow sensitive or business-critical data from entry to storage, integrations, display, deletion, and export. Check permission boundaries and what is left behind when an action fails.

3. Exercise the core journey

   Use realistic records on the target devices and connection conditions. Include an invalid input, a timeout, a repeated action, and a return visit so the review tests behavior rather than screenshots.

4. Separate blockers from investments

   A missing recovery path may block launch; a hard-to-change component may be a follow-up investment. Label both clearly so the team does not confuse “not perfect” with “not safe.”

A useful deliverable

For each finding, record the evidence, affected journey, consequence, likelihood, recommendation, owner, and decision date. A short register that someone can act on is more valuable than a long list of technical opinions without a launch recommendation.