Production Readiness Checklist Before Launch or Funding

Launch day, a big customer pilot, a press mention, or a funding push: all of them send unusual traffic and unusual scrutiny at a system that has so far only been used by friends. If it falls over, you find out in public. If an investor's technical advisor looks closely, you find out in diligence.

This is a checklist you can run with your engineer in about two hours. Each item has a check that takes roughly 15 minutes, and a red, amber or green test written so you can judge the answer even if you cannot read code. Copy it into your own doc and fill it in.

How to use it

Sit next to whoever runs your systems. Ask them to show you each check on screen, not describe it. "We have backups" and "here is the last successful backup and here is the restore we did in March" are very different answers.

Scoring: Green means it is in place and you saw it. Amber means partly in place or nobody has tested it. Red means missing, or the answer was "I think so." Any red in sections 1 to 4 should block launch. Amber items get a name and a date.

The scorecard

1. Reliability: what happens when something breaks

Why it matters: One server, one database or one person is a single point of failure.

15-minute check: Ask: "If our main server or database vanished right now, what do customers see and how long until they are back?" Ask to see where each part runs and whether there is more than one of anything critical.

Green: a clear written answer with a recovery time, and it has been tried at least once.
Amber: an answer exists but it has never been tried, or it depends on one person.
Red: "we would figure it out," or a single database with no standby and no tested recovery.

2. Monitoring and alerting: do you hear it first

Why it matters: The worst way to learn about an outage is a customer tweet.

15-minute check: Open the dashboard. Can you see error rate, response time and whether the site is up? Then ask the engineer to trigger a harmless test alert. Does it reach a phone, and whose?

Green: errors, speed and uptime visible on one screen; an alert reached a named person in under 5 minutes during the test.
Amber: dashboards exist, but alerts go to an email inbox or a channel nobody watches at night.
Red: no alerts, or you learn about issues from customers.

3. Backups and a tested restore

Why it matters: A backup you have never restored is a hope, not a backup.

15-minute check: Ask for the date of the most recent automatic backup, and the date of the last time someone restored one into a test environment and checked the data.

Green: daily or better backups, plus a restore test in the last 3 months, with the time it took written down.
Amber: backups run, but no restore has ever been tried.
Red: no automatic backups, or backups stored in the same place as the live data with no separate copy.

4. Security basics

Why it matters: Most startup breaches come from basic gaps, not clever attackers.

15-minute check: Four quick questions. (a) Is two-factor login on for every cloud, code and email admin account? (b) Are passwords and API keys kept out of the code repository? (c) Is the database blocked from the public internet? (d) When someone leaves the team, how fast is their access removed?

Green: yes to all four, and leaver access is removed the same day.
Amber: one or two gaps with a dated plan to close them.
Red: shared logins, secrets in the code, a database open to the internet, or "we have not checked."

5. Deploys and rollback

Why it matters: Launch week is when you will push many fixes. A bad release must be reversible in minutes.

15-minute check: Ask to watch a deploy of a trivial change to production, then ask how they would undo it.

Green: deploy is one command or button, takes minutes, and rollback to the previous version is a practised step.
Amber: deploy works but is manual, only one person can do it, or rollback is "redeploy the old code and hope."
Red: deploys involve editing files on a live server, or database changes cannot be reversed.

6. Cost guardrails

Why it matters: Traffic spikes can also produce a bill spike, and a runaway job can burn a month's budget over a weekend.

15-minute check: Open the cloud billing page. Is there a budget alert set? Can the engineer name the three biggest line items and why they are that size? If you use paid AI or SMS APIs, is there a spending cap?

Green: budget alerts set at a sensible monthly figure, top costs explained, caps on third-party usage.
Amber: alerts exist but nobody has looked at the breakdown.
Red: no alerts, no caps, and a surprise on last month's bill. For deeper work see how to reduce AWS cost.

7. Ownership and runbooks

Why it matters: At 2 a.m. during launch you need to know who acts and what they do.

15-minute check: Ask: "Who gets woken up, and where is the one-page note that says what to check first?" Also confirm your company, not a contractor, owns the cloud account, code repository, domain and key vendor accounts.

Green: named on-call person and backup, a short written runbook for the top 3 failures, company-owned accounts.
Amber: the knowledge exists but lives in one person's head.
Red: nobody is named, or a freelancer is the only account owner.

8. Load expectations

Why it matters: "It works" with 5 users says little about 500 at once.

15-minute check: Write down the busiest realistic moment (for example "800 people sign up within one hour after the email goes out"). Ask: "Has anything like that been simulated, and what broke first?"

Green: a simple load test at 2 to 3 times expected peak was run and the weak spot was fixed or understood.
Amber: estimated on paper only, no test.
Red: no expected number, or the system slowed or failed at a level you expect to see.

For your CTO or engineers

Quick technical versions of the same checks:

Reliability: multi-AZ database with automated failover enabled; stateless app instances behind a load balancer; health checks that fail on dependency issues.
Monitoring: the four golden signals (latency, traffic, errors, saturation); alert on symptoms customers feel, not raw CPU; use p95 and p99, not averages. See SLOs and error budgets.
Backups: point-in-time recovery enabled, cross-account or cross-region copy, restore drill recorded with real elapsed time.
Security: MFA everywhere, least-privilege IAM, secrets in a manager, private subnets for data stores, dependency scanning in CI, TLS everywhere.
Deploys: CI-built immutable artefacts, backward-compatible migrations (expand then contract), feature flags for risky changes.
Cost: budget alarms, anomaly detection, per-environment tags, rate limits and hard caps on paid APIs.
Load: test the real user journey including the database, with realistic data volume. Then use the backend scaling checklist for the bottlenecks found.

Example (illustrative)

A hypothetical 12-person B2B SaaS startup is two months from a Series A process and about to onboard its first large customer. The CEO runs the scorecard with the lead engineer.

Results: reliability amber (single database, no standby, never tested), monitoring green, backups red for restore (daily backups exist, no one has ever restored one), security amber (two ex-contractors still had access), deploys green, cost amber, ownership red (the cloud account was in a former contractor's name), load amber (nothing tested).

Two reds and four ambers. The team spends about two working weeks: moves account ownership, runs a restore (it takes 3 hours, longer than they assumed, so they document it), removes old access, adds a database standby, and runs a load test at 3x the new customer's expected usage, which exposes one slow report query. After the fixes the board is mostly green with the load and cost items still amber and dated. The numbers here are invented to show the process, not a record of any client.

The value is not the score. It is that the founder walks into diligence with a written, honest answer instead of an improvised one.

When NOT to do this

Do not run the full list on a pre-launch prototype with ten test users. Do sections 3 and 4 (backups and security basics) only; the rest is premature. See what to build and skip in an MVP.
Do not chase all-green before launching. Green everywhere is a sign you waited too long. Fix reds, date the ambers, ship.
Do not let this list stand in for a regulated-industry review. If you handle health or payment data, this is a starting point, not a compliance assessment.
Do not self-score alone. The person who built the system will mark it more kindly than it deserves.

Common mistakes

Accepting "yes, we have that" without watching it work.
Treating a backup as proven because the job says "succeeded."
Alerts that go to a shared channel everyone has muted.
Load testing only the homepage, not the signup or checkout path.
Doing the check once and never again. Re-run it before every major event.
Leaving the cloud account in someone else's name.

Checklist

Copy this block into your own document.

Scoring: G = green (seen working), A = amber (partial or untested), R = red (missing). Reds in 1 to 4 block launch.

Reliability [ G / A / R ]
- Written answer to "what if the main server or database disappears" with a recovery time
- Tried at least once
Monitoring and alerting [ G / A / R ]
- Errors, speed and uptime visible on one screen
- Test alert reached a named person within 5 minutes
Backups and tested restore [ G / A / R ]
- Automatic backups, copy held separately from live data
- Restore tested in the last 3 months, time recorded
Security basics [ G / A / R ]
- Two-factor on all admin accounts
- No secrets in code
- Database not open to the internet
- Leaver access removed same day
Deploy and rollback [ G / A / R ]
- Deploy takes minutes and is repeatable by two people
- Rollback practised
Cost guardrails [ G / A / R ]
- Budget alert set
- Top three costs explained
- Caps on paid third-party usage
Ownership and runbooks [ G / A / R ]
- Named on-call and backup
- One-page runbook for the top three failures
- Company owns cloud, code, domain and vendor accounts
Load expectations [ G / A / R ]
- Peak number written down
- Tested at 2 to 3 times that peak, weak spot understood

Date run: ______ Run by: ______ Owner of each amber: ______ Fix-by date: ______

Want someone to run this with you?

If you would like an outside engineer to walk through this scorecard with your team before a launch or a raise, that is the core of my MVP to Production Systems work. Book a free 30-minute technical review on the contact page. You can also see how I approached a high-volume payments platform in this case study.

FAQ

How long does a production readiness check take?

The scorecard itself takes about two hours with an engineer at your side. Fixing the reds usually takes days to a couple of weeks, depending on how many there are.

Do investors actually ask about this?

Technical diligence varies by investor and stage, but questions about backups, security and who owns the accounts are common. Having a written answer saves time and builds trust.

Who should run the checklist?

Someone who did not build the system, ideally with the builder present to demonstrate. That could be another engineer, a fractional CTO or an outside reviewer.

How often should we repeat it?

Before every major launch, big customer onboarding or fundraise, and at least every six months otherwise. Restore tests in particular should be repeated on a schedule.