Introduction

You shipped fast. Real users showed up, or a term sheet is on the calendar, and now someone is asking whether the product can handle either one. The honest answer usually sits somewhere between the demo that impressed early adopters and the system that won’t lose data under concurrent writes.

The distinction matters because a prototype and an MVP are not the same artifact wearing different names. A prototype is built expecting to be thrown away, which is what makes it fast and cheap; the moment a team starts treating it as a permanent asset instead, it becomes a liability. The problem is that most teams don’t notice the transition happening. They keep adding features to code that was never meant to carry load, and the gap between what the product looks like and what it can actually survive keeps widening quietly until an incident, a funding diligence call, or a traffic spike exposes it all at once.

This checklist separates cosmetic readiness gaps, the ones that annoy users but rarely break anything, from structural gaps, the ones that show up repeatedly in early-stage production incident postmortems: data loss, outages, and security exposure. Each item below names what to observe, what it might mean, and what evidence actually confirms the diagnosis, because a single symptom is not proof of a structural defect.

Data integrity: the gaps that cause silent loss, not loud outages

Data loss rarely announces itself. It shows up weeks later as a support ticket about a missing record, and by then the audit trail to explain it is gone. Four checks matter here.

Backups exist but have never been restored. Observed symptom: a backup job runs on schedule and reports success. Possible cause: the backup is real, or it’s capturing a corrupted schema, an empty table, or a partial write. Evidence needed: a documented, timed test restore to a clean environment within the last quarter. A green backup log without a restore test is not evidence of recoverability.

No idempotency on write-heavy endpoints. Observed symptom: duplicate charges, duplicate orders, or duplicate records appear under retries or double-clicks. Possible cause: the client is misbehaving, or the server has no idempotency key check. Evidence needed: reproduce the retry under load and confirm whether the server deduplicates or the database constraint catches it.

Soft deletes without a clear reversal path. Observed symptom: users report missing data after deleting the wrong record. Possible cause: the delete is a true hard delete, or a soft delete exists but no tooling exposes it to support staff. Evidence needed: a documented procedure, not just a database flag, for reversing a deletion within a defined window.

Migrations run directly against production with no rollback plan. Observed symptom: a schema change was applied manually during a deploy window. Possible cause: the team has a tested rollback script, or they are relying on hope. Evidence needed: a rollback script that has actually been exercised, not just written.

Related Zenveus resource: Code Rescue insights.

Load and concurrency: where demos lie and real traffic tells the truth

A demo with one user clicking through a flow tests almost nothing about production behavior. The following checks reveal what concurrency actually does to the system.

No rate limiting on public endpoints. Observed symptom: the API has no throttling configured. Possible cause: it was never needed at demo traffic, or it will fail the first time a script, bot, or legitimate traffic spike hits it. Evidence needed: a load test at two to three times expected peak traffic, checking whether the service degrades gracefully or falls over entirely.

Database connections are unpooled or under-provisioned. Observed symptom: intermittent timeout errors appear only during busier periods. Possible cause: a connection pool limit set for development traffic, or a genuine database capacity ceiling. Evidence needed: connection pool metrics during a simulated concurrency spike, not just application logs after the fact.

Background jobs have no retry or dead-letter handling. Observed symptom: a job fails silently and the triggering event is simply gone. Possible cause: the job queue has no failure handling configured, which means transient errors permanently drop work. Evidence needed: force a job failure in staging and confirm whether it retries, alerts, or vanishes.

Single points of failure in the deploy path. Observed symptom: one server, one region, or one manual step stands between the product and downtime. GetDX describes this pattern as a single point of approval or control becoming the constraint on every readiness decision, and the same logic applies to infrastructure: one unredundant component is the ceiling on your uptime (GetDX).

Security and access: the gaps that turn a bug into a breach

Security gaps are the hardest category to self-diagnose because the system usually works fine until someone deliberately or accidentally does the wrong thing. OWASP’s agent security guidance generalizes well beyond AI features: classify data before anything, human or automated, can touch it, and separate decision-making from execution for any action that can’t be undone (OWASP).

Admin and support tooling share the same auth as customer-facing login. Observed symptom: one login system grants access to both regular accounts and internal admin functions. Possible cause: this was faster to build, but it means a credential leak or a privilege escalation bug exposes everything at once. Evidence needed: confirm whether admin actions require a separate authentication path and audit log.

No audit log for sensitive actions. Observed symptom: support staff or automated processes can modify financial data, user records, or production config with no trace. LastPass’s 2026 checklist specifically names financial transactions, sensitive data access, and production system changes as categories that should never run unattended or unlogged (LastPass). Evidence needed: pull the audit log for the last sensitive action taken and confirm it captures who, what, and when.

If AI agents or automation touch production data, check scope. MoClaw names excessive permissions and unsafe tool access, alongside prompt injection and data leakage, as the failures that actually cause incidents rather than theoretical risks (MoClaw). Evidence needed: confirm any agent or automated process runs under a scoped, least-privilege credential rather than a broad service account, and that irreversible actions require human approval (Hatchworks).

Scoring the checklist and deciding what to fix first

Not every gap deserves the same urgency. Score each item you flagged above on two axes: how likely it is to trigger under real conditions, and how bad the outcome is if it does. A missing idempotency check on a low-traffic internal tool is low urgency. A missing idempotency check on checkout is a structural defect that needs fixing before the next funding call or traffic spike, not after.

Treat the checklist as a menu matched to what you actually shipped, not a mandate applied uniformly, and assign one named owner to every item you decide to fix, since shared ownership on a small team quietly becomes no ownership (Userpilot). Cortex’s guidance applies directly here too: keep the unresolved items visible to whoever is making the business decision, whether that’s a cofounder or an investor, rather than letting them sit unaddressed in a backlog nobody revisits (Cortex).

If you’re heading into technical due diligence, the gaps above are close to what a diligence reviewer checks first, because they map directly to the questions investors ask about data integrity, uptime risk, and security exposure. If you’re not sure how your product scores against this list, Zenveus’s Production Readiness Self-Check walks through the same categories in more depth, and the Diligence Self-Assessment is built specifically for the fundraising version of this question.