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

What LaunchGate checks

Four areas, inspected before launch.

Each area is scored out of 100. Every problem we find comes with proof, how serious it is, and how to fix it.

  • 13 key checks

    Security

    Find vulnerabilities, exposed secrets, insecure configurations, authorization issues, and risky dependencies.

    Example findingFictional sample
    High severity main.js · line 14

    Exposed API key in frontend code

    // in the public JS bundle
const apiKey = "sk_live_••••••";

    Recommended fixMove the key to a server-side function, then rotate it.

  • 11 key checks

    Privacy

    Detect tracking, privacy-policy mismatches, consent problems, retention gaps, and risky data flows.

    Example findingsFictional sample

    3rd-party trackers

    • Google Analytics Before consent
    • Meta Pixel Before consent
    • Segment After consent
  • 12 key checks

    Legal readiness

    Review policies, disclosures, subscription terms, refund language, accessibility notices, and regulatory readiness.

    Example findingsFictional sample
    • Privacy PolicyFound
    • Terms of ServiceMissing
    • Cookie ConsentMissing
    • AI DisclosureFound

    Flagged for attorney review, not legal advice.

  • 12 key checks

    Reliability

    Identify performance risks, broken flows, accessibility issues, configuration errors, missing monitoring, and weak recovery plans.

    Example findingsFictional sample

    Core Web Vitals score / 100

    • LCP Loading Pass
    • INP Responsiveness Pass
    • CLS Stability Pass

LaunchGate identifies issues based on the checks performed. Some findings may require attorney or specialist review. Which checks run depends on your package and the scope in your signed permission form.

Inspection area · 13 key checks

Security checks

We test how your app behaves, not only what its code says. Each check is reported as pass, warning or blocker, with the evidence behind it.

Access control

  • Can one user see or change another user's data?Signed in as one test account, we request another account's records by changing IDs. The server must refuse.
  • Can a normal user make themselves an admin?A regular account calls admin routes and APIs directly and tries to change its own role. Expect 401 or 403.
  • Are database and storage rules switched on and tested?Row-level security and bucket permissions, tried as an anonymous visitor, a user and an admin.

Secrets and sign-in

  • Are keys or secrets exposed in the browser, the code history or the logs?Frontend bundles, source, git history and deploy config scanned for keys that belong only on the server.
  • Where do sign-in tokens live, and do they expire?Cookie flags, token storage, session expiry and whether logging out really ends the session.
  • Can a login redirect be pointed at someone else's site?OAuth redirect URIs, state and PKCE, and ?next= style parameters tried with outside addresses.
  • Do repeated login attempts get slowed down or blocked?Rate limits on login, signup, password reset and one-time codes, per address and per account.

Payments

  • Can prices or payments be changed from the browser?We edit the amount or product in the checkout request. The server should look up the real price itself.
  • Can payment webhooks be faked or replayed?Unsigned, altered and duplicate webhook calls should be rejected or handled safely.

Inputs, uploads and AI

  • Is every input checked on the server?Validation and escaping, with injection, cross-site scripting and mass-assignment probes.
  • Are file uploads restricted and stored privately?File type and signature checks, size limits, random names, private storage and download permissions.
  • Can a hidden instruction trick your AI features?Prompt injection through documents and pages, tool permissions, and whether one account's AI can reach another account's data.
  • Are security headers and dependencies in order?Content-Security-Policy, HSTS and related headers, plus packages with known vulnerabilities.

These are the key checks in this area; a full audit runs many more. The Free Launch Check is a preliminary public-surface review and is not equivalent to a full audit. Read the methodology

Run a free launch check

Inspection area · 11 key checks

Privacy checks

A cookie banner or a privacy policy is not proof on its own. We compare what your app says with what it actually sends and stores.

Tracking and consent

  • Do trackers load before a visitor agrees?Each page type opened in a fresh browser, recording every network request before the banner is touched.
  • Does "Reject" actually stop them?After reject or withdrawal, optional trackers should stay off. Global Privacy Control signals are checked too.
  • What cookies, pixels and SDKs are on the site?An inventory sorted into necessary, analytics, functional and advertising, with unknown items investigated.

Data map

  • What personal data do you collect, where does it go and how long do you keep it?Data, source, purpose, storage, retention, who can access it and how it is deleted.
  • Which outside services receive user data?A vendor list covering analytics, payments, AI, email and storage, with what each one receives.
  • What is sent to an outside AI provider?Prompts, files and personal data passed to AI features, and whether your policy mentions it.
  • Are you collecting data you never use?Unused fields, analytics events and tracking parameters that add risk without adding value.

User rights

  • Can users delete their account, and does it really go?We create and delete a test account, then check profiles, uploads, records and AI history.
  • Can users export their data or make a privacy request?Download and request routes, where you offer them or may need them.

Policy against code

  • Does your privacy policy match what the code really does?Statements in the policy compared with the network log, the database and the vendor list.
  • Is personal data kept out of logs and error reports?Log calls and error payloads checked for emails, tokens and other personal data.

These are the key checks in this area; a full audit runs many more. The Free Launch Check is a preliminary public-surface review and is not equivalent to a full audit. Read the methodology

Run a free launch check

Inspection area · 12 key checks

Legal readiness checks

Flagged for attorney review

LaunchGate flags issues for attorney review. LaunchGate is not a law firm and does not provide legal advice.

Documents

  • Is there a privacy policy, and does it describe your real practices?Present, linked from signup, checkout and the footer, and specific to your app rather than copied.
  • Do users accept your terms in a way you can show later?Terms linked at signup and checkout, and how acceptance is recorded.
  • Are refund and cancellation terms easy to find?Eligibility, deadlines and how to cancel, stated plainly rather than buried.
  • Does your cookie policy match the cookies we found?Compared against the tracker inventory from the privacy checks.
  • Is there an accessibility notice?A statement with a target standard and a way for people to report problems.

Subscriptions and claims

  • Is auto-renewal disclosed before purchase?Price, billing frequency, renewal date and how to cancel, shown before the customer pays.
  • Are there pressure tactics in the flow?Pre-ticked add-ons, hidden fees, fake timers, confusing opt-outs and hard-to-find cancellation.
  • Can you back up your marketing claims and testimonials?Security, privacy and AI claims on your site compared with what the product actually does.
  • Do users know when they are talking to AI?AI disclosures, and whether AI output could be read as medical, legal or financial advice.

Sensitive audiences and contact

  • Could children or schools use your app?Signals that children's or student data rules may apply, flagged for attorney or specialist review.
  • Do marketing emails and texts have proper opt-in and opt-out?Sender identity, unsubscribe links, and records of consent for SMS.
  • Can customers tell who runs the service and how to reach you?Business name, support contact and refund or billing help.

These are the key checks in this area; a full audit runs many more. The Free Launch Check is a preliminary public-surface review and is not equivalent to a full audit. Read the methodology

Run a free launch check

Inspection area · 12 key checks

Reliability checks

Building the feature is half the job. These checks ask whether you will know when something breaks, and whether you can recover when it does.

Testing and release

  • Do your tests cover the risky paths?A suite that runs with one command and passes today, covering sign-in, permissions and payments.
  • Can you roll back a bad deploy?A known previous version, a rollback procedure and recoverable database migrations.
  • Are staging and production kept apart?Separate data, separate keys and clearly labelled environments.

Monitoring

  • Will you find out when something breaks?Front-end and server error reporting, with alerts that reach a person.
  • Is there a health check and uptime alert?A health endpoint that checks critical dependencies, watched by an outside monitor.
  • Can one user run up your bill?Spending caps and usage alerts for AI, email, SMS and other metered services.

Recovery

  • Has a backup restore actually been tested?Evidence of a real restore and verification, not only a backup setting that is switched on.
  • Do error pages leak internal details?Stack traces, keys, internal paths or raw database errors shown to users.
  • Is there a plan for a leaked key or an outage?Who detects, contains, rotates and notifies, and in what order.

Experience

  • Can people use it with a keyboard and a screen reader?Labels, keyboard use, visible focus, contrast and error messages that say how to fix the problem (a WCAG-oriented review).
  • How fast and stable are your key pages?Core Web Vitals: loading (LCP), responsiveness (INP) and layout stability (CLS), on mobile too.
  • Do the critical flows work on a phone?Signup, checkout and core tasks on a small screen and a slow connection.

These are the key checks in this area; a full audit runs many more. The Free Launch Check is a preliminary public-surface review and is not equivalent to a full audit. Read the methodology

Run a free launch check

Inside the gate

Four inspection chambers.

Every audit runs your app through four separate inspections, each with its own tests and its own findings. Open a chamber to watch one of its tests run on a fictional app.

Chamber SEC · Security

Can one customer reach another customer's data?

A typical test signs in as two separate test accounts and tries to cross the line between them, edits what the browser sends, and maps what your AI agent is allowed to touch.

Educational demo

Cross-account data-access test

Version of the app to test
  1. User A signs in and gets a session token.
  2. User A requests GET /api/notes/8821. Auth sees a valid token and lets it through.
  3. The API fetches note 8821 by its ID. It never asks who owns it.
  4. The database returns the note. Its owner is User B.
  5. Response 200 OK: User A is reading User B's private note.
  1. User A signs in and gets a session token.
  2. User A requests GET /api/notes/8821. Auth sees a valid token and lets it through.
  3. The API compares the note's owner with the signed-in user: User B, not User A.
  4. Response 403 Forbidden. The note is never sent.

Blocker · Cross-account read

Any signed-in user can read any note by changing the ID in the request.

Pass · Ownership checked

The server checks who owns each note before returning it. The retest gets 403 for every other user's note.

AI agent permission map

AI agent
  • Email Sends as any user Drafts only; a person sends
  • Database Reads and writes every table Reads the signed-in user's rows
  • Payments Issues refunds, edits prices No access
  • Files Reads every upload Reads files the user attached
  • Browser Opens any URL No access
  • Users Changes roles, deletes accounts No access

Over-permissioned agent

Six tools, no limits. One hidden instruction in an uploaded document could send email, move money or make a user an admin.

Least privilege

Three tools, each limited to the signed-in user. Payments, browsing and user admin are removed, and a person sends every email.

Payment tampering test

As built

Pro plan$99
// POST /api/checkout
{ "plan": "pro",
  "amount": was 9900, edited to 1 }
  1. The amount is edited in the browser before it is sent.
  2. The server charges whatever amount arrives: $0.01.
Price tampering detected

After fix

Pro plan$99
// POST /api/checkout
{ "product_id": "PRO" }
  1. The server looks up the trusted price for PRO: $99.00.
  2. Stripe charges $99.00. The browser never sends a price.
Price set by the server

Tests in this chamber

  • Cross-account access
  • Admin authorization
  • Exposed secrets
  • Payment tampering
  • Webhook verification
  • Injection
  • AI prompt injection
  • Rate limiting
  • File uploads
  • Session safety

Chamber PRV · Privacy

Where does personal data actually go?

We map every service your app sends personal data to, then check each flow against your privacy policy and your cookie banner. Select a service to see what reaches it.

Educational demo
Your app

Source · people using your app

Users

Data collected
Name, email, password (stored hashed), note text, IP address
Shared with
Your app only
Retention
Until the account is deleted, but users have no way to delete it
Purpose
Run accounts and store notes
Consent requirement
Privacy notice linked at sign-up
Policy status
No deletion pathThe policy promises deletion on request; the app has no way to do it.

Destination · database and sign-in

Supabase

Data collected
Account records, notes, session tokens
Shared with
Supabase, as database and sign-in host
Retention
Until deleted, plus 7 days of backups
Purpose
Store data and sign users in
Consent requirement
Listed as a service provider
Policy status
DisclosedNamed in section 4, “Service providers”.

Destination · payments

Stripe

Data collected
Name, email, billing country. Card numbers go straight to Stripe's hosted checkout.
Shared with
Stripe, as payment processor
Retention
Your app keeps only the Stripe customer ID
Purpose
Charge subscriptions
Consent requirement
Listed as a payment processor
Policy status
DisclosedNamed in section 4, “Service providers”.

Destination · AI provider

OpenAI

Data collected
Note text a user asks to summarise
Shared with
OpenAI API
Retention
Set by the provider's API terms; your policy doesn't mention it
Purpose
Generate note summaries
Consent requirement
Disclose before sending; whether opt-in is needed goes to attorney review
Policy status
Policy mismatchThe policy says notes “never leave our servers”. Network traffic shows note text sent to an AI API.

Destination · analytics

Google Analytics

Data collected
IP address, device info, page activity
Shared with
Google
Retention
Set in the analytics account; your policy doesn't say
Purpose
Measure visits and sign-ups
Consent requirement
Consent required before it loads
Policy status
Privacy mismatchObserved: the analytics script loads before the visitor answers the cookie banner.

Destination · email

Email provider

Data collected
Email address, name, sign-up and receipt events
Shared with
Transactional email provider
Retention
Not stated; the provider keeps send logs
Purpose
Account emails, receipts, a monthly newsletter
Consent requirement
Newsletter needs opt-in; the sign-up box is pre-ticked
Policy status
Retention unclearThe provider is named; how long it keeps data is not.

Destination · file storage

Storage

Data collected
Uploaded attachments and their file names
Shared with
Private storage bucket
Retention
Files stay after their note is deleted
Purpose
Note attachments
Consent requirement
Covered by the privacy notice
Policy status
Files keptThe policy says deleted notes are erased; their attachments remain.

Destination · error monitoring

Monitoring

Data collected
Error traces, some with email addresses and request bodies
Shared with
Error-monitoring service
Retention
90 days on the current plan
Purpose
Find and fix crashes
Consent requirement
Listed as a service provider
Policy status
ReviewDisclosed, but traces carry more personal data than they need.

Consent rules depend on where your users are and what you collect. LaunchGate identifies issues based on the checks performed; some findings may require attorney or specialist review.

Tests in this chamber

  • Trackers before consent
  • Third-party data flows
  • Retention
  • Account deletion
  • Policy vs. reality

Chamber LGL · Legal readiness

Do your documents describe the app you actually built?

Policies and terms go through the scanner line by line and are compared with what the app was seen doing. Gaps are flagged for your attorney to decide.

Educational demo

Document scanner

privacy-policy.html

Privacy Policy
  • What data is collectedDisclosedSection 2 lists account, usage and payment data.
  • Privacy contactFoundA contact address is listed in section 9.
  • How long data is keptUnclearSays “as long as necessary”, with no periods given.
  • AI provider that receives notesMissingNote text goes to an AI API, but no AI provider is named.

subscription-terms.html

Subscription Terms
  • PriceFound“$99 per month” appears next to the Pro plan.
  • Auto-renewalUnclearNowhere says the plan renews automatically, or when.
  • How to cancelHard to findCancel steps sit in a help article, three clicks from the account page.

Scan complete: 4 items found, 2 warnings and 2 blockers, all flagged for attorney review.

Flagged for attorney review

LaunchGate flags issues for attorney review. LaunchGate is not a law firm and does not provide legal advice.

Documents this chamber reads

  • Privacy Policy
  • Terms of Service
  • Refund policy
  • Cookie policy
  • Accessibility statement
  • Subscription renewal
  • Cancellation
  • Marketing claims
  • Testimonials
  • Children's data
  • AI disclosures

Chamber REL · Reliability

Will it stay up, recover, and work without a mouse?

We check how your app is tested, deployed, watched and restored, and whether people can use it with a keyboard and read it comfortably.

Educational demo

Launch control room

Fictional sample
  • 2 verified
  • 2 warnings
  • 1 blocker
  • 1 review
  • 1 not tested

  • Automated tests

    Verified

    Run on every push; the last run passed.

  • Deploy gate

    Bypassable

    The hotfix branch deploys without running tests.

  • Health checks

    Verified

    /healthz answers 200 and checks the database.

  • Error monitoring

    Partial

    Browser errors are captured; API errors go nowhere.

  • Backups, restore-tested

    Restore untested

    Nightly backups run; nobody has tried a restore.

  • Logging

    Review

    Logs keep full request bodies, including emails.

  • Alerts

    Not tested

    No alert routing was found to test.

Keyboard trap test

Version of the checkout dialog to test
  1. Tab Focus moves to Email.
  2. Tab Card number.
  3. Tab Pay $99.
  4. Tab Back to Email. The Close button is never reached.
  5. Esc Nothing happens.
  6. Focus trapped: a keyboard user cannot leave checkout.
  1. Tab Focus moves to Email.
  2. Tab Card number.
  3. Tab Pay $99.
  4. Tab Close button.
  5. Esc Checkout closes and focus returns to the Upgrade button.

Keyboard trap detected

WCAG 2.2 criterion 2.1.2, No Keyboard Trap: keyboard users are stuck in the checkout dialog.

Corrected

Close is reachable, Esc closes the dialog, and focus returns to the button that opened it.

Text contrast check

Continue to payment
3.1:1 Fail Body text needs at least 4.5:1.
Continue to payment
7.2:1 Pass Clears 4.5:1 with room to spare.

Tests in this chamber

  • Automated tests
  • Deploy gates
  • Health checks
  • Error monitoring
  • Backups and restores
  • Mobile testing
  • Accessibility
  • Logging
  • Alerts

LaunchGate identifies issues based on the checks performed. Some findings may require attorney or specialist review.

See the full methodology