Product

Launch Check can now see your app. We tested that claim on our own site before writing this.

Two things shipped this week: the code scanner now catches a class of bug that has nothing to do with security in the usual sense, and Launch Check stopped judging your app blind. Here's what changed, and what happened when we pointed both at ourselves.

1. The scanner now catches "the AI only wrote the happy path"

AI coding tools are very good at making the demo work. They're much less reliable at handling what happens when Stripe calls your webhook twice, or a payment comes back pending instead of paid. Those paths don't show up in a five-minute test, so they don't get written — until a real customer hits one in production.

We added a new category to the scanner for exactly this: missing state handling. It looks for stateful flows — payments, orders, subscriptions, webhooks — that only implement the success path, with no branch for the realistic failure states.

Here's the scanner running on a Stripe webhook handler that already had signature verification done correctly (the part everyone remembers to check):

critical | Missing State Handling | No guard against duplicate or replayed webhook events
warning  | Missing State Handling | No handling for payment_intent.payment_failed or checkout.session.expired
warning  | Missing State Handling | No handling for async payment methods that stay in 'pending'

Notice the first one is critical, not a style nitpick. Stripe guarantees at-least-once delivery — the same webhook event can arrive twice. A handler with no idempotency check will happily process a duplicate and double-fulfil an order. That's a real bug hiding inside what looks like a completeness gap, and the scanner correctly told the two apart on its own — it doesn't flag every payment flow just for existing, only ones that visibly reach a real failure state with no branch for it.

2. Launch Check was writing reports blind. It isn't anymore.

Launch Check opens your app in a real browser, clicks through a few pages, and captures screenshots. Those screenshots were always shown to you in the report. What we hadn't noticed until we looked closely: they were never actually sent to the model writing the report. It was judging your app's UX from numbers — "this page has 2 buttons and 1 form" — never from what the page actually looked like.

We fixed that. The screenshots now go to the model along with the technical evidence, and the report splits into two sections instead of one flat list: What needs fixing (crashes, console errors, broken requests — objectively broken) and UX & flow issues (friction a first-time visitor would hit — nothing crashed, but it might cost you the visitor).

We didn't just ship this. We ran it on ourselves.

Before writing this post, we pointed Launch Check at our own /learn page and asked it to confirm a visitor could reach pricing and the free scan.

That was a real, specific finding about our own live site, not a hypothetical. So we fixed it — added the missing nav links, and while we were at it, ran the same audit across every other page sharing that nav template. Then we ran Launch Check again.

Better — and it confirmed the fix in its own words: "Visitors can clearly reach both Pricing and the free scan from the /learn page via the top navigation bar." But it kept going, because the bot's journey that run happened to click through to /how-it-works and /login, and found two more real, smaller gaps: the How It Works page's nav was missing a Sign In link, and the login page had no navigation at all beyond a single "back to home" text link. Fixed both. Ran it a third time.

The only thing left was a wording mismatch — one page's button said "Scan your code" while every other page said "Start free scan." Same link, inconsistent label. Fixed that too.

Why we're telling you this instead of just changing a changelog

Three consecutive real findings, each one different from the last, each one true about our own production site, each one we verified live rather than assumed fixed. That's the actual proof this is worth anything — not "the model can now see images," but "the model looked at our own app and found three real problems in a row, and stopped finding new ones once they were actually fixed."

FAQ

Related: