The Software Rescue Checklist Every Founder Should Have Before Launch

A software rescue checklist is a pre-launch risk assessment that tests seven things: code health, architecture, security, testing, performance, ownership, and rollback readiness. Run it four to six weeks out and you catch the failures that would otherwise find you at 2am on day three.

Inside this blog:

• The seven-part checklist, written for founders who do not read code

• A launch readiness scorecard you can complete this afternoon

• The exact crash and ANR thresholds Google uses to decide whether to promote or bury your app

• Five signs you have moved past checklist territory and into rescue territory

Every founder we meet three weeks before launch says a version of the same sentence. "We're basically done; we just need to tidy a few things up."

We have been building and rescuing software in Melbourne since 2011, and we can tell you what "a few things" usually means. It means nobody has load tested. It means the payment webhook has no retry logic. It means your contractor still owns the App Store account. A software rescue checklist exists to surface all of that while it is still boring to fix, instead of after your first hundred users have already found it.

Products rarely die because the idea was wrong. They die because something small and invisible sat broken for six weeks and no one had a reason to look.

What is a Software Rescue Checklist?

A software rescue checklist is a pre-launch risk assessment tool that evaluates a software product across seven areas: code quality, architecture, security, testing, performance, ownership, and incident readiness. It identifies what is likely to fail after launch, then ranks those risks by business impact rather than by technical difficulty.

That is different from QA. Your QA process asks whether the button works. A rescue checklist asks what happens when four thousand people press the button at the same time, on bad hotel Wi-Fi, with an expired card.

The economics are why this matters. The Consortium for Information and Software Quality puts the cost of poor software quality in the US at $2.41 trillion, with about $1.52 trillion of that sitting in accumulated technical debt. Macro numbers, sure. But the mechanics scale right down to a seed-stage startup. A defect caught in code review costs an hour of someone's time. The same defect caught by a paying customer costs a refund, a support thread, a churned account, and a one-star review that will still be sitting on your listing next Christmas.

Why Launch Readiness Got Harder in 2026

Short version? Everyone ships faster than they can check their own work now.

Google's DORA research found 90% of technology professionals now use AI in their daily work, up 14 points in a single year. Same research, less flattering finding: AI adoption correlates with higher delivery instability. More code, more often, more change failures.

Then it gets worse. Faros AI, looking at engineering telemetry across roughly 22,000 developers, found incidents per pull request up 242.7%. Bugs per developer up 54%. And 31% more pull requests merging with nobody reviewing them at all.

So the volume of code in your product went up. The human attention per line went down. Your technical debt compounds quietly in the background the whole time, and launch day is when it presents the invoice.

AI did not break your process. It just ran your existing process at four times the speed, which is a different problem entirely.

The Software Rescue Checklist: 7 Things to Check Before You Ship

Work through these in order. If you cannot answer something, that is a finding. Write it down.

1. Code health and technical debt

1. Fresh eyes on the code. Someone who did not write it needs to read it. Non-negotiable. And if you do not have a second senior developer on the payroll, you can still have an outside engineer read it line by line at no cost.

2. Secrets audit. No API keys, passwords or tokens in the repo. Check commit history too, because deleting a key from a file does not delete it from git.

3. Dependencies. Are they current? Does anything carry a known critical vulnerability?

4. Clean-machine build. Can a new developer clone, build and run in under two hours using written instructions? If it only works on Dave's laptop, you do not have a product. You have Dave.

5. Dead code, orphaned branches, commented-out experiments: delete them.

2. Architecture and scalability

1. Know your peak. What is your expected concurrent user count, and have you load tested at three times that?

2. Database indexes. Every field you filter or sort by needs one. This single item has fixed more "our app is slow" complaints than any other.

3. Single points of failure. What one component, if it dies, takes the whole thing with it?

4. Third-party calls. Timeouts, retries, and a defined behaviour when the vendor goes down. They will go down.

5. Adding capacity should mean spending money, not rewriting code.

Architecture problems are the expensive category because they are structural. We went deeper on how weak foundations turn into business risk if you want the long form.

3. Security and compliance

1. Auth and sessions reviewed against the OWASP Top 10.

2. Encryption in transit and at rest. Both. Not one.

3. Permission testing. Log in as a basic user and actively try to reach admin data. Do not assume, attempt.

4. Australian founders: confirm your obligations under the Privacy Act and the Australian Privacy Principles, including notifiable breach requirements. We have watched local startups discover these on the same day as their first incident. It is not a good day.

5. Your privacy policy should match what the product actually collects. Usually it does not.

4. Application testing strategy

Here is where things get messy, because this is the section founders quietly skip.

1. Critical paths covered by automated tests: signup, login, payment, and whatever your core action is.

2. Tests run on every merge, and a failing test blocks the merge. Otherwise they are decoration.

3. Real devices. Simulators lie. Cheap Android handsets lie the most convincingly.

4. Edge cases: no internet, throttled 3G, declined card, double submission, back button halfway through checkout.

5. Ten people outside your team using the product with nobody watching over their shoulder. Watch what they do wrong. That is your roadmap.

A good application testing strategy is not about hitting a coverage percentage. It is about identifying the four or five flows that generate all your revenue and defending those like your funding depends on it. Which, roughly speaking, it does.

5. Performance and stability thresholds

App stores enforce quality with real consequences, and most founders find this out the hard way. Google publishes bad behaviour thresholds in Android vitals. Cross a 1.09% user-perceived crash rate and your app becomes less discoverable across every device. Cross 8% on a single phone model and Play can slap a warning on your store listing.

6. Ownership, access, and documentation

Ignore this one at your own peril. It is the least technical section on the list and it has ended more startups than bad code ever has.

1. Source code ownership assigned to your company in writing. Not implied. Not verbal. Written.

2. Admin access to repo, cloud accounts, domain, App Store Connect and Play Console, held by you.

3. Billing on a company card. When it sits on a contractor's personal card, you are one dispute away from your servers going dark.

4. A README covering architecture, environment variables and deployment steps.

5. Could you replace your entire dev team next month and survive? Answer honestly.

Two or more unchecked here? Stop reading. Go fix them today.

7. Launch day and rollback readiness

1. Rollback in under fifteen minutes, and you have actually practised it.

2. Error monitoring live and alerting a named human's phone, not a shared inbox nobody opens.

3. Backups automated, and a restore tested. An untested backup is a rumour.

4. Staged rollout: 5%, then 25%, then everyone.

5. Someone on call by name for the first 72 hours. "The team" is not a name.

Two famous failures make this case better than we can. Knight Capital lost more than $400 million in about 45 minutes in 2012 when a deployment reached seven of eight servers and nobody could reverse it fast enough. CrowdStrike's 2024 update took down roughly 8.5 million Windows machines globally, traced to a content update that was not staged. Neither was a coding failure. Both were release and rollback failures.

‍

‍

Score Your Launch Readiness

Give each of the seven sections a score from 0 to 3. Zero means you have not looked. One means you looked and did not like what you found. Two means it is handled but undocumented, which is a polite way of saying it lives inside one person's head. Three means you have evidence, not vibes.

Do this with your lead developer in the room and do it out loud. Scores have a habit of dropping the moment someone has to say "yes, we tested the restore" to another human's face rather than tick a box in private. And treat a perfect 21 on the first pass with suspicion. We have seen it twice in fifteen years, and one of those turned out to be wrong.

Most startup app checklist reviews we run land somewhere between 11 and 15. That is not a failing grade. It usually means the product itself works fine and everything around it does not: no monitoring, no rollback, no documentation, no idea what happens under real load.

How to Run a Pre-launch Software Audit in 10 Days

Days 1 to 2. Inventory. Every repo, service, third-party account, dependency. Who has access to what, and who should not.

Days 3 to 5. Read and stress it. Independent code review, dependency scan, load test at triple your expected peak.

Days 6 to 7. Break it deliberately. Kill the database connection mid-request. Expire a token halfway through a session. Submit the same payment twice. Then go look at what the user actually saw.

Days 8 to 9. Fix and verify. Triage by business impact, not by what is easiest to knock over. Re-test everything you touched.

Day 10. Decide. Score the seven sections and set your launch date off the score. Not off the calendar. Not off the investor update you already sent.

Five Signs You Need a Rescue, Not a Checklist

1. Estimates stopped meaning anything. Everything has been "almost done" for three weeks.

2. There is a file nobody wants to touch. That is fear. Fear is technical debt you can measure in body language.

3. Fixing one thing breaks another. Missing tests, tangled dependencies, or both.

4. Nobody can explain the architecture in plain English. Either it is too complex or it was never designed in the first place.

5. You genuinely do not know what percentage of the product is finished.

Three or more of those and a checklist will not save your launch date. We covered the rest of the warning signs that software is becoming unmanageable in more detail.

Here is the thing we keep coming back to after fifteen years of MVP rescues, technical debt audits and custom software builds. The founders who launch cleanly are almost never the ones with the most elegant code. They are the ones who assumed something would break and made a plan for it in advance.

That is all a rescue checklist really is. Not pessimism. Just planning that happens early enough to be useful.

‍

‍