Skip to main content
LaunchGateAUDIT TODAY. LAUNCH TOMORROW.
Run a free launch check

Methodology

What we check, and where we stop.

A LaunchGate audit inspects an app across four areas: security, privacy, legal readiness and reliability. Every finding is recorded with evidence, the test that proved it and a fix. This page shows the method, how findings are rated, and its limits.

Inspection map

Ten stations, one gate

Pick a station to see what it looks at, how it's tested and what evidence you get. Only the surface scan works from outside, looking at what any visitor can see. Everything past the gate needs your code and a safe copy of your app.

Outside the gate

Surface scan

What any visitor, or attacker, can see without logging in.

What it looks at
Your public pages, the code and files your site sends to every browser, response headers and HTTPS, which outside services load, whether trackers fire before consent, and whether policy pages exist and are linked.
How it's tested
Public pages are loaded in a fresh browser with no stored consent, and every network request is recorded along with what the browser receives. No logins, no attack tests.
Evidence you get
The request list, the headers, and the exact page or file where something shows up.
Where it stops
It can't see behind a login, into your server code or into your database rules. This is the scope of the Free Launch Check: a preliminary public-surface review, not a full audit.

Security

Code review

A map of how your app really works, built before anything is tested.

What it looks at
Routes and API endpoints, database rules and migrations, sign-in and sessions, storage, payments, forms, analytics, AI features, email and admin areas.
How it's tested
Reading the code through read-only access, and tracing where each input is checked and where each permission is enforced: on the server, not just hidden in the interface.
Evidence you get
File and line references for every finding.
Where it stops
Only the code we're given access to. Hosting dashboards, live settings and vendor contracts we can't see are listed as needing your evidence, never marked as passed.

Security

Access-control tests

Can one user reach another user's data, or make themselves an admin?

What it looks at
Every route and record that belongs to a user, a team or an admin.
How it's tested
On a safe copy with test accounts: anonymous visitor to user, User A to User B, user to admin. IDs are changed, requests modified and admin routes called directly.
Example
Educational demo 
// signed in as User A
GET /api/notes/{User B's note id}
expected 403 · observed 200 OK
Evidence you get
The exact request, the response, and what it exposed.
Where it stops
The routes and roles in scope. Hands-on testing by a licensed security firm goes further, and we'll say when it's worth it.

Security

Secret scanning

Keys, tokens and passwords that should never reach a browser or a log.

What it looks at
The JavaScript sent to browsers, the repository and its history, config files and logs, including card details, passwords or tokens written to logs.
How it's tested
Pattern scans of the shipped code, the git history and log files, then a manual check of every hit.
Evidence you get
Where each secret was found, with its value redacted in the report.
Where it stops
You rotate an exposed key at its provider; we flag it as a launch blocker. A key that was ever exposed stays a finding until it has been rotated.

Security

Payment tests

Is the price decided by your server, or by whoever edits the request?

What it looks at
Where prices, plans and “paid” status are decided; whether webhooks are signature-checked and handled once; whether card data ever touches your own server.
How it's tested
On the safe copy, in the payment processor's test mode: the amount or plan in a request is changed, and webhooks are replayed or forged.
Example
Educational demo 
// request edited in the browser
{ plan: "team", price: "0.01" }
server ignores it and charges its own price
Evidence you get
The modified request and what it was charged or granted.
Where it stops
This isn't a PCI DSS assessment. If card data was ever stored or logged, you need a PCI Qualified Security Assessor (QSA).

Privacy

Privacy & data-flow review

Where personal data goes, and whether your privacy policy says the same.

What it looks at
What personal data you collect, which services receive it (database, analytics, AI provider, email, payment processor), how long it's kept, and whether people can export or delete it.
How it's tested
A data map built from the code and from real network traffic, compared line by line with your privacy policy. Deletion is tested to see that it really deletes, and trackers are tested against consent choices.
Evidence you get
The data map, request logs, and the policy sentence quoted next to the code that contradicts it.
Where it stops
Which privacy laws apply to you, and what they require, is a question for an attorney.

Legal readiness

Legal-readiness checks

The pages and promises a launch needs, checked against what the product does.

What it looks at
Privacy policy, terms, refund policy, cookie notice, accessibility statement, subscription renewal and cancellation wording, marketing claims and testimonials, children's data and AI disclosures.
How it's tested
Each one is checked for whether it exists, is linked where people need it (footer, sign-up, checkout) and matches how the product really behaves.
Evidence you get
The page or screen, the quoted text, and the behaviour it doesn't match.
Where it stops
LaunchGate flags issues for attorney review. LaunchGate is not a law firm and does not provide legal advice.

Reliability

Reliability checks

Will you find out when something breaks, and can you recover?

What it looks at
Tests on the risky paths, deploy gates, health checks, error alerts, logs kept free of personal data, rate limits and spending caps, backups and restore tests, and a separate staging environment.
How it's tested
Running the test suite, reviewing deploy, logging and monitoring settings, checking that a failure raises an alert to a person instead of waiting for a user to complain, and asking for restore evidence.
Evidence you get
Test output and configuration references. Anything only you can show, such as backups, hosting or DNS, is listed as needing your evidence.
Where it stops
A backup that exists but has never been restored is reported as untested, not passed.

Reliability

Accessibility checks

Can someone sign up, sign in and pay using only a keyboard?

What it looks at
The critical flows (sign-up, sign-in, checkout and key forms) for keyboard use, visible focus, labels, error messages, contrast, target size and zoom.
How it's tested
Keyboard-only walk-throughs, contrast measurements and automated checks, measured against WCAG 2.2 AA.
Evidence you get
The screen and step where it fails: focus trapped inside a checkout dialog, for example.
Where it stops
A full WCAG 2.2 AA review with assistive technology is work for an accessibility specialist.

After fixes

Retesting

The same test, with the same accounts, after your fix.

What it looks at
Every P0 and P1 finding, once a fix is in.
How it's tested
The test that found the problem is run again, with the same request and the same accounts, and the new result is recorded next to the old one.
Evidence you get
Before and after results side by side. A finding is marked verified only when the original test passes.
Where it stops
A retest covers the findings retested. Later changes to code, settings or providers mean the affected checks need to run again.

Scope

What we test, and what we don't

Testing only ever covers what your signed permission form lists.

What we test

  • Your code, through read-only access
  • A staging or test copy, with test accounts
  • Your public pages and everything a browser receives
  • Payment flows, in the processor's test mode
  • Your policies, compared with what the code does
  • Critical flows with a keyboard, against WCAG 2.2 AA

Not included

  • Legal advice or a legal opinion
  • Formal certifications or attestations, such as PCI DSS or SOC 2
  • A full manual penetration test by a licensed security firm, unless arranged
  • Attack tests against your live system or your real users' data
  • Anything not listed on your signed permission form
  • A promise that nothing else is wrong: results cover the checks performed

Specialists

When you need a specialist

Some findings need a licence or a specialty that LaunchGate doesn't provide. Some findings may require attorney or specialist review, and the report names who and why.

  • Attorney

    Privacy policy and terms, refunds and auto-renewal, AI disclosures, testimonials and marketing claims, children's data, which privacy laws apply, and breach-notification duties.

  • Accessibility specialist

    A full WCAG 2.2 AA review with assistive technology, beyond our checks of the critical flows.

  • PCI Qualified Security Assessor

    If real card data was ever stored, logged or sent through your own server.

  • Security firm

    A hands-on penetration test after fixes, especially for apps that hold sensitive data.

  • Accountant

    Tax and payment set-up, where relevant.

Severity

How serious is each finding?

Every finding gets exactly one level, and the level decides what has to happen before launch.

  1. P0 · CriticalDo not launch

    Fix before any real user arrives.

    ExamplesExposed secret keys; one user reading another's data; broken sign-in; payment manipulation; a publicly readable database; a known critical vulnerability; trackers firing without required consent; children's data without required protections.

  2. P1 · HighFix before public release

    Fix before the app opens to the public.

    ExamplesIncomplete privacy disclosures; missing rate limits; critical flows that don't work with a keyboard; a broken consent flow; unsafe file uploads; no monitoring.

  3. P2 · MediumFix soon

    Put it on the list and fix it soon.

    ExamplesMinor accessibility issues; incomplete logs; unclear interface text; extra hardening.

  4. PassChecked, with evidence

    The control was tested and there's evidence it works.

    Wording“No technical evidence of noncompliance detected for the controls tested.”

  5. UnverifiedA pass without evidence

    It may well be fine, but nobody has shown it yet.

    ExamplesBackups, hosting settings, DNS and email set-up, vendor contracts: items only you can show stay here until you do.

Launch recommendation

One recommendation, not a certificate

A report ends with exactly one of three recommendations, based on the checks performed.

  • No-go

    Do not launch

    At least one P0 is open

    Real users would be exposed to a critical problem. Fix the blockers, then retest.

  • Conditional go

    Limited beta only

    No P0 open; risks remain

    Open to a small, known group while the remaining high risks are fixed before a public release.

  • Go

    Ready for controlled production launch

    Never given with an open P0

    A recommendation for a careful launch based on the checks performed. It is not a certification.

Scores

Four scores, never one

Security, privacy, legal readiness and reliability are each scored out of 100. Scores are weighted by risk, not a count of passed checks, so one critical problem can sink a score. Sign-in, data exposure, payments, children's data, AI autonomy and attack surface weigh more than cosmetic issues.

Fictional sample

Scores from the sample report for Notely, a made-up app.

  • 0–49 Blocker
  • 50–74 Warning
  • 75–100 Pass

  • Security

    5/100

    Blocker

  • Privacy

    10/100

    Blocker

  • Legal readiness

    10/100

    Blocker

  • Reliability

    25/100

    Blocker

Next to the scores, a report counts launch blockers and high risks, items that need your own evidence, and items for attorney review.

Evidence

Every finding carries its proof

Each finding follows the same chain, so you can check our work and your developer can reproduce it. A pass without evidence is recorded as unverified.

Fictional sample One finding from the Notely sample report P0 · Critical
Control
The rule being checked
Users can only reach their own data
Applicability
Why the rule applies to this app, or why it doesn't
Notely has accounts and private notes
Risk
What could happen, and the severity
P0: a customer's private notes are exposed to every other customer
Evidence
Where it was seen: file, route, response or setting
GET /api/notes/:id looks up the note by ID only, with no owner check
Exploit test
What was tried, and what happened
Signed in as User A, requested User B's note: 200 OK with B's title and text
Fix
The change that closes it
Add the owner to the query (WHERE id = ? AND user_id = ?) and a User A to User B regression test
Tested
When, and when it must run again
24 Oct 2026; again after the fix, and whenever access rules change
Confidence
How sure we are
High: reproduced

Retests

Retests, and why a pass has a date

A finding is closed by evidence, not by a promise that it's fixed.

  1. FoundA test shows the problem.
  2. FixedYour team, or ours, ships a fix. It isn't closed yet.
  3. RetestingThe same test runs again.
  4. VerifiedThe original test now passes.

Results describe the code, settings and date in the report. When the relevant code, dependencies, database rules, payment logic or providers change, the affected checks need to run again.

Our rule set treats a pass as out of date after 90 days, or after 30 days for sign-in, payments, children's data, AI tools and database access rules. Every report names the rule-set version it was run against.

See the method applied

The sample report runs this method on a fictional app, from scores to fix roadmap.

The Free Launch Check is a preliminary public-surface review and is not equivalent to a full audit.

Run a free launch check Open the sample report