What we check in a launch-readiness review

Example failure modes

• ✕Unlimited password attempts, so leaked credentials from elsewhere can be tested against your users at speed.
• ✕Rate limiting applied per IP only, so rotating addresses bypasses it entirely.
• ✕Signup with no verification, letting a script create thousands of accounts that inflate usage and cost.
• ✕A per-request AI or SMS call with no cap, turning a loop into an invoice.
• ✕Nothing alerts anyone while any of the above is happening.

Evidence that may be requested

• →Rate-limit and lockout configuration, if any exists
• →Two test accounts you create and control
• →Which public actions incur a per-call cost
• →Any existing alerting on failed logins or signup spikes

Not covered

• —Running a credential-stuffing campaign against your live users
• —Denial-of-service or load testing of any kind
• —Testing with real leaked credential datasets
• —Bot-mitigation product selection or configuration

Example failure modes

• ✕Changing an identifier in a request and receiving another account's record.
• ✕A control hidden in the interface while the endpoint behind it still succeeds.
• ✕Row-level security switched on with a policy that matches every row.
• ✕A list filtered in the browser rather than in the query, so the full set is still sent.
• ✕File or attachment URLs that are guessable and need no sign-in.

Evidence that may be requested

• →Two or more test accounts at different privilege levels
• →Role and permission matrix, however informal
• →Read-only view of database access policies
• →Storage bucket or file access rules

Not covered

• —Exhaustive enumeration of every route and parameter combination
• —Access to or extraction of real customer data — reviews use test data only
• —Privilege escalation against third-party infrastructure

Example failure modes

• ✕A debug or admin route left deployed and reachable by URL.
• ✕A webhook endpoint that processes anything posted to it, signed or not.
• ✕An internal action (issue credit, change a role, export data) callable directly.
• ✕Stack traces or database errors returned to the caller.
• ✕Validation enforced only in the browser, so a direct request bypasses it.
• ✕Uploaded files served from predictable URLs with no access check.

Evidence that may be requested

• →List of public routes and endpoints, if one exists
• →Webhook endpoint configuration
• →Storage and file-serving configuration
• →The deployed client bundle, which is already public

Not covered

• —Formal exploit campaigns or proof-of-exploit development
• —Exhaustive injection testing across every parameter
• —Network or infrastructure penetration testing
• —Scanning or testing systems you do not own or control

Example failure modes

• ✕Payment succeeds, the confirmation event is missed, access is never granted.
• ✕The same provider event processed twice, unlocking or crediting twice.
• ✕Amounts stored as floating point, so a small balance reports as zero.
• ✕Mixed currency codes treated as interchangeable.
• ✕A manual balance adjustment made outside the ledger, later overwritten or clawed back.
• ✕Refunds and cancellations that never revoke the access they paid for.
• ✕Nothing that periodically compares your records against the provider's.

Evidence that may be requested

• →Test-mode provider access (read-only)
• →Webhook configuration and a recent delivery log
• →How amounts and currencies are stored
• →Whether a ledger exists, and how manual adjustments are made
• →A description of what each payment outcome should unlock

Not covered

• —Testing with real cards or real customer money
• —Tax, invoicing, accounting or chargeback-dispute advice
• —PCI compliance certification
• —A full financial audit of historical transactions

Example failure modes

• ✕An older update applied after a newer one, reverting the displayed value.
• ✕A duplicate message applied twice, double-counting a change.
• ✕A snapshot fetched on reconnect that silently replaces fresher local state.
• ✕Two concurrent transactions both reading the old value and both writing.
• ✕Frontend state drifting from server truth with no mechanism to resynchronise.
• ✕No sequence or version field, so ordering cannot be established even in principle.

Evidence that may be requested

• →How realtime updates are delivered and subscribed to
• →Whether events carry a sequence, version or timestamp
• →Transaction and locking approach for concurrent writes
• →Reconnect behaviour after a dropped connection

Not covered

• —Distributed-systems formal verification or consensus proofs
• —Load testing to induce contention at scale
• —Rewriting your state-management architecture

Example failure modes

• ✕A job that is not idempotent, so a retry applies the same change twice.
• ✕Two instances of the same job overlapping with no lock.
• ✕A partial failure leaving half the records updated and half not.
• ✕An expiry or TTL rule applied to a key that means more than intended.
• ✕A bulk correction run straight against production with no dry-run.
• ✕Silent failure — the job stops running and nobody notices for weeks.

Evidence that may be requested

• →List of scheduled jobs and what each is for
• →Job execution history or logs, if retained
• →Locking, retry and idempotency approach
• →Any expiry, TTL or cleanup rules and what they apply to
• →Whether a dry-run mode exists for corrective jobs

Not covered

• —Running your jobs against production on your behalf
• —Rewriting or re-architecting the job system
• —Auditing every historical job execution

Example failure modes

• ✕A service-role key present in client-side JavaScript.
• ✕A publishable key relied on for protection while the access policies are permissive.
• ✕Credentials committed to git history and still valid.
• ✕An inbound callback trusted without verifying it came from the provider.
• ✕One shared key used everywhere, so rotating it means an outage.

Evidence that may be requested

• →Environment variable names (values are never requested)
• →The deployed client bundle, which is already public
• →A list of third-party services in use and what each can reach
• →Callback and webhook authentication configuration

Not covered

• —Auditing the security of the third-party providers themselves
• —Reviewing secrets you do not disclose or that sit outside the agreed scope
• —Any request for the secret values themselves

Example failure modes

• ✕Client-side errors never recorded, so blank screens are invisible.
• ✕Logs that cannot be tied to a release, so nobody knows which change caused it.
• ✕Alerting on everything, so real alerts are ignored.
• ✕A rollback that reverts code while leaving migrated data in the new shape.
• ✕Backups configured but never restored, so recovery time is unknown.
• ✕No named person with authority to decide to roll back.

Evidence that may be requested

• →Read-only access to error tracking or logs, if any exists
• →Recent deployment history and rollback procedure
• →Backup schedule, retention, and evidence of any restore performed
• →Any alert routing currently configured

Not covered

• —Building or configuring a monitoring stack for you
• —Performing a production restore on your behalf
• —Ongoing monitoring after the review window
• —Formal disaster-recovery certification or RTO/RPO sign-off

Example failure modes

• ✕Repository living in a contractor's organisation with the founder as a collaborator.
• ✕Domain registered on a developer's personal account.
• ✕Payment provider account owned by an agency, so payouts route through them.
• ✕One shared login for everything, with no record of who did what.
• ✕Deployment only possible from one person's machine.

Evidence that may be requested

• →List of every account the app depends on
• →Owner and billing owner for each
• →Who can currently revoke whose access
• →Any handover documentation that exists

Not covered

• —Legal advice on contracts, IP assignment or disputes
• —Negotiating with your contractor or agency on your behalf
• —Performing account transfers for you