PanicLab (panic.design)

Stress-test product flows for moments when everything goes wrong. Panic Lab turns screenshots into panic scenarios, failure timelines, scores, and design fixes.

Comment

Inspiration

Most product reviews happen in calm conditions. Real users hit the product when something is already going wrong: a payment fails, a reservation timer is running, recovery copy is vague, context is degraded, and the consequence is immediate.

That is the gap Panic Lab is built for. I wanted a way to test the moment where a flow starts to panic before users discover it in production.

The domain topic, panic.design, pushed the product shape in a useful direction. It should not just be a marketing site or a report viewer. The panic case should be the protocol: the user state, the trigger, the time pressure, the recovery pressure, the consequence, the evidence, and the fix.

What it does

Panic Lab is a private native macOS lab for stress-testing critical product flows under pressure.

In the Mac app, a designer can collect or import evidence, author a Panic Profile, run a Panic Test, and review the result in Run Studio. The review is evidence-linked: it keeps the frames ordered, supports annotations, records run history, breaks the score down by panic dimension, and preserves fix notes.

The public site is the protocol surface. It can browse seeded Panic Profiles, validate imported artifact JSON, replay public Panic Reports, render Panic Cards, and explain the field guide behind panic testing.

The boundary is the product: private evidence stays local, and public sharing is explicit through portable schema-backed artifacts.

How we built it

The native lab is a SwiftUI macOS app with local persistence and a small shared design system. The artifact model is shared across Swift packages and the web surface so profiles, tests, reports, cards, and bundles stay portable.

The public site is built with Astro, React, and TypeScript. A Hono API validates imported artifacts and serves the demo-critical protocol routes. The deployed submission runs on Cloudflare Pages and Pages Functions.

The evaluation path is intentionally reliable. Panic Lab can attempt an on-device Foundation Models draft when the machine and model state support it, but the demo does not depend on that. A deterministic evaluator keeps the workflow usable, and every exported report carries provenance and uncertainty.

The macOS app is distributed from a separate public release repository so the private source repo can stay private while judges can still download a notarized app build.

Challenges

The hardest design challenge was keeping this from turning into a generic audit tool. The useful part is not just scoring a flow. It is preserving the panic context: what the user is trying to do, what failed, what pressure they are under, what they stand to lose, and which evidence proves the finding.

The hardest implementation challenge was making the private/public boundary real. The Mac app needs to handle messy private evidence, but the public website should only receive deliberate portable artifacts. That meant defining a schema-backed artifact protocol and validating the handoff instead of assuming everything could live in one hosted workspace.

Foundation Models also needed a conservative integration. If the model is available, it can help draft an evidence-linked report. If it is not available, the app still works. I did not want the demo path or the product value to depend on a best-case machine state.

What we learned

The strongest product shape is local-first. Product teams already have sensitive screenshots, flow notes, and failure cases. Asking them to upload that evidence into a new cloud account would weaken the idea. Keeping the lab native and private makes the public artifact more trustworthy.

I also learned that the public site has to be more than a brochure. panic.design works when it behaves like a protocol surface: import JSON, validate it, replay it, and make the failure legible to someone who was not in the original review.

What's next

The next useful slice is deeper real-use authoring: more Panic Profile templates, better before-and-after fix tracking, richer Run Studio comparison between runs, and a smoother final export flow.

I would still avoid accounts, cloud sync, arbitrary crawling, browser extensions, and benchmark aggregation until the core loop is stronger. The core loop is the value: private native lab, portable public artifact, and a repeatable way to design for the moment everything goes wrong.

Built With

  • app-intents
  • astro
  • cloudflare-pages
  • cloudflare-pages-functions
  • foundation-models
  • github-releases
  • hono
  • json-schema
  • notarytool
  • openapi
  • playwright
  • react
  • swift
  • swift-testing
  • swiftdata
  • swiftui
  • typescript
  • vitest
Share this project:

Updates