Methodology
How a launch-readiness review is actually run
Every review follows the same nine stages: authorization and scope, safe test accounts, critical-path mapping, verification under normal, failure and abuse conditions, evidence collection, severity classification, verdict, delivery, and one recheck. Findings are labelled REPRODUCED, VERIFIED, OBSERVED, NOT VERIFIED or OUT OF SCOPE — and missing evidence is never treated as assurance.
This is a scoped launch-readiness review. Applicable paths depend on how your app handles accounts, customer data, payments, integrations and production operations.
Written and reviewed by Rohit · Last reviewed 27 August 2026
- 01
Authorization and scope confirmation
Nothing is touched until you confirm in writing that you own the app or are authorized to have it reviewed, and accept the disclosed scope. The named app, environment and boundaries are agreed before access is requested. A request that cannot be authorized is declined and refunded.
- 02
Safe test accounts and environments
Reviews run on staging or a live app using accounts created for the review, never on real customer records. At least two accounts at different privilege levels are needed to check separation at all. Access is read-only wherever read-only is sufficient, and you revoke it when the report lands.
- 03
Critical-path mapping
Before testing anything, the paths that carry money, identity or customer data are written down: sign-up, sign-in, the core action your product exists to perform, payment, and anything that grants or removes access. Scope follows consequence, not code volume.
- 04
Normal, failure and abuse-path verification
Each critical path is exercised three ways. Normal: it does what it should. Failure: a declined card, a dropped connection, a closed tab mid-flow, a duplicate event. Abuse: a signed-in user requesting something belonging to another account, or calling an endpoint the interface does not expose. Most findings come from the second and third pass.
- 05
Evidence collection
Anything reported is recorded as it was found: the request, the response, the configuration, the screen. If it can be triggered again, it is triggered again before it is written up. Evidence is captured with test data only and stored for the retention period in the privacy notice.
- 06
Severity classification
P0 blocks launch — money, customer data or account integrity is at risk on a path real users will take. P1 should be fixed before real volume, or before the next release. P2 is worth doing and will not hurt you next week. Severity reflects consequence to you, not how technically interesting the finding is.
- 07
Verdict criteria
GO: nothing found blocks launch on the paths reviewed. CONDITIONAL GO: launch is reasonable once specific, named items are fixed — those items are listed explicitly. NO-GO: at least one finding would cause loss of money, data or customer trust on the paths reviewed. The verdict always states what it covers and what it does not.
- 08
Report delivery
A private recorded walkthrough plus a written report: executive summary, verdict, findings ordered by severity with evidence labels, developer-ready remediation notes, and an explicit list of what was out of scope. Delivered through the private channel agreed at onboarding. The 48-hour review window starts after payment, written authorization, agreed scope and complete usable access are all in place.
- 09
Recheck rules
One recheck of agreed P0/P1 fixes is included, for fixes submitted within seven days of delivery. The recheck confirms whether the specific finding is resolved; it is not a second full review, and it does not re-open scope. Seven days of written clarification runs alongside it.
Evidence labels
Every important finding carries one label, so you always know how strongly it is backed. These are the same labels used in the service terms.
- REPRODUCED
- I triggered the behaviour myself, more than once, and can show the steps.
- VERIFIED
- Confirmed directly against configuration, logs or provider dashboards.
- OBSERVED
- Seen once or inferred from strong indirect signals, but not reproduced on demand.
- NOT VERIFIED
- Could not be checked in the agreed window or with the access provided. Recorded as unknown, never as safe.
- OUT OF SCOPE
- Deliberately excluded from this review. Listed so nothing looks silently skipped.
Missing evidence is not assurance. NOT VERIFIED means unknown — it does not mean safe.
Limitations
- A review reflects the evidence available in an agreed window on an agreed scope. Nine founder-risk areas are considered; the critical paths actually exercised are the ones applicable to your app, agreed in writing beforehand. It is not a statement that every route in all nine areas was tested, nor that every vulnerability, bug or fraud path has been found.
- This is not a formal penetration test, an exploit campaign, a load or denial-of-service test, or a compliance certification.
- No implementation work is performed on a reviewed app. Findings are written for whoever maintains it.
- Findings age. A verdict describes the app as it was during the review window; a later release can invalidate any of it.
- Areas that cannot be checked with the access provided are labelled NOT VERIFIED and listed, not quietly omitted.
This is the process your app would go through.
Fixed scope · Independent review · No rebuild pitch