Skip to main content

LaunchAudit

A LaunchAudit is a one-time, fully automatic pre-launch check of your site. You give VeriWasp a URL, pay once ($5, no subscription), and it does everything else: it maps your site, writes real browser tests for your critical flows by itself, runs them, sweeps every page for accessibility and breakage problems, checks your SEO and security headers, and delivers one combined report. There is nothing to install, no scripts to write, and no setup beyond the one form.

It exists for one moment: the week you launch. It is the fastest way to find out what a stranger hitting your site tomorrow will actually experience.

What you get​

One report at a private link (also emailed to you), covering:

  • Your critical flows, tested in a real browser. VeriWasp's AI looks at your site and writes the tests itself: signing up, your primary call to action, search, contact forms, and similar paths a new visitor would take. Each flow runs in a real Chrome browser with a screenshot at every step, and each links to its own full step-by-step report.
  • Accessibility. A sitewide scan (up to 15 pages) for WCAG violations, ranked by severity, with a link to the full accessibility report and fix guidance.
  • Page health. JS errors, failed requests, and broken images, page by page.
  • SEO, link previews, and security headers. Missing titles and descriptions, incomplete Open Graph tags (what makes shares look bare on X and Slack), missing sitemap, and the security headers that protect your visitors (HSTS, CSP, clickjacking protection, and more).
  • A PDF export of the whole report, for forwarding or filing.

Audits usually finish in under ten minutes. The progress page updates live, and the report link lands in your inbox when it is done, so you can close the tab.

How it works​

  1. Go to veriwasp.com/audit. Enter your site's URL and the email address the report should go to. If parts of your site are behind a sign-in, see the next section.
  2. Pay via Stripe. The audit starts the moment payment clears.
  3. VeriWasp crawls your site, decides which user flows matter, writes the tests, runs them, and compiles the report.
  4. You get the report link by email. The link is private (an unguessable URL) and shareable with anyone you send it to.

An account is created for you automatically under the email you gave (or the audit runs under your existing account if you are signed in). That matters because of what comes next.

Auditing behind a sign-in​

This part matters: without a sign-in, the audit can only test what a logged-out visitor can reach. Anything behind your login wall (a dashboard, an onboarding flow, the first real action) is invisible to it. Give the audit a way in and it tests the signed-in experience too. Two options, both optional, both encrypted in transit and at rest and never shown on any report:

Option 1: a test account with a password. Give the login page URL, a username, and a password. VeriWasp signs in the same way a person would (it finds the form fields itself) before running each flow. Use a dedicated test account, not your own. These credentials are saved to your account as a reusable authentication profile, so the tests keep working if you keep them.

Option 2: sign in with anything, then hand over the session. If your app signs in with a magic link, Google, GitHub, SSO, or passkeys, scripted login does not apply. Instead: sign in to your site in your own browser, open devtools (Application, then Cookies), and paste your session cookie(s) into the audit form as name=value, one per line. VeriWasp replays that session for the audit's tests. This works with every sign-in mechanism, because you did the signing in.

Handed-over session cookies get a stricter promise than the password option: they are used only inside the audit's own test browser, and they are deleted the moment the audit finishes, whether it succeeded or failed. They are never stored beyond the audit, never shown anywhere, and never used for anything except running your audit's tests. (This also means that if you later keep the tests, you will add a sign-in on your account at that point, since the audit deliberately kept nothing.)

If the session expires mid-audit and there is no password to fall back on, the affected flows run signed-out and the report says so honestly, rather than failing the whole audit.

Keeping the tests​

This is the part that makes a LaunchAudit more than a report. The browser tests VeriWasp writes for your audit are real playtests, saved on your account from the moment they are created. After the audit:

  • Subscribe, and those exact tests re-run whenever you want: before the next release, on a schedule, or automatically on every pull request through the GitHub App. Nothing to rewrite, nothing to re-record.
  • If the audit used a password sign-in, it was saved as a reusable authentication profile on your account, so the adopted tests keep working behind your login. (Handed-over session cookies are deleted when the audit finishes, per the promise above, so cookie-based audits add a sign-in later if the tests are kept.)

If you never subscribe, nothing bad happens: you keep the report and the account, and the tests simply sit there until you want them.

What the audit does, and will not do, to your data​

These are real browser tests on your live site, so they can create real data: a test signup lands a real row in your users table, a contact-form test sends you a real message. Everything created uses clearly synthetic values (generated emails like playtest+abc123@example.com), so it is easy to spot and clean up, and the report shows you every step that ran, exactly as it ran.

What the audit will never do:

  • It never enters payment details, not even test card numbers. Checkout flows are verified up to the payment page and stop there.
  • It never deletes or modifies existing data, changes account settings, or performs anything irreversible. This is enforced twice: the AI that writes the flows is forbidden from proposing such steps, and a safety filter drops any generated step that reads like acting on existing data (delete, remove, deactivate, cancel account, and similar) before it can run.
  • Form submissions are limited to things clearly meant for the site owner (a signup, a contact form) and use obviously synthetic data.
  • It only audits publicly reachable sites, and only the one you point it at.

If your production database must stay pristine, point the audit at your staging or preview URL instead; it works the same way.

Where a flow needs unique data (a signup email, for example) the tests use generated values, so re-running them later never collides with earlier runs.

Testing signup all the way through, and checkout​

A signup flow does not have to stop at "account created." The browser session that signed up is signed in, so the generated flow can continue into the app: through onboarding, to the first real action a new user would take. The audit's flows go as deep as a single session allows.

Checkout flows are verified to the edge of money: the flow walks to the payment page and asserts it loads correctly, then stops. If you want a full checkout tested end to end, run it yourself as a regular playtest against a Stripe test-mode environment; playtests support Stripe's standard test card there.

Limits​

To keep the audit fast and the price low, each audit covers up to 15 crawled pages, up to 4 authored flows, and per-page health checks on the 5 most central pages. That comfortably covers a pre-launch site; if you need more than that, you are exactly who the subscription is for.

If something goes wrong​

If the audit cannot finish (for example, the site could not be crawled), the report page says exactly why, and nothing is silently lost. Write to support@veriwasp.com and we will re-run it or refund you.