flightrec/ vision

The flight recorder for the App Router.

Flightrec records a full Next.js session as a replayable trace — Server Actions, cache, RSC payloads, cookies/headers, and the client tree — and lets engineers rewind it on one timeline.

v0.1 · alpha·MIT core + cloud·built in public · @buildwithgg
01 / 10
The problem

App Router apps are hard to debug because the story is scattered.

State spans the boundary

Server and client state split across two execution models.

Rendering is streamed

RSC payloads arrive in chunks; the UI changes over time.

Cache is invisible

updateTag vs revalidateTag — freshness is never surfaced.

No tool unifies it

Logs, traces, metrics, firewall rules each see one slice.

02 / 10
Why now

The ecosystem just admitted it needs a richer debugging surface.

Server Actions are first-class

Vercel exposes them as operational entities in firewall tooling.

Next.js ships MCP

next-devtools-mcp exposes errors, logs, routes, get_server_action_by_id.

Observability ≠ replay

Logs, traces, OTEL export — but no human-first time-travel over RSC.

The signals are there — Flightrec is the missing human-first replay layer on top of them.

03 / 10
The product

One debugger, six planes, one timeline.

01User action
02Server Action
03Cache invalidation
04RSC payload
05Response mutation
06Client tree

Unifying these six planes against a single scrubber is the wedge — versus observability, runtime metadata, or generic session replay.

04 / 10
The experience

Scroll the session. Watch the bug happen.

Server Action

Which function ran, with what args, and its outcome — mapped to your source.

RSC Payload

Ordered Flight frames, parsed and diffed as they streamed in.

Client Patch

The exact tree nodes created, patched, and removed on reconcile.

Cache outcomes are classified automatically — immediate-freshness, stale-then-refresh, no-visible-effect, or orphaned — so you see whether the user actually got fresh data.

05 / 10
Market gap

Adjacent tools each see one slice. None replay the whole chain.

Replay.io

Time-travel — for client JS. No Server Actions, cache, or RSC.

Sentry Replay

Records the DOM, not server causality.

Vercel Observability

Logs, traces, metrics — not session replay.

Next.js MCP / OTel

Runtime metadata and spans — diagnostics, not replay.

06 / 10
How it works

Capture both sides. Normalize. Replay deterministically.

01
User interaction
02
Server + client capture
03
Normalize → reconcile
04
IndexedDB / .frec
05
Inspector replay

No shadow React runtime — a deterministic replay graph with checkpoint snapshots. MCP enriches; it is never the source of truth. The .frec bundle is self-contained.

07 / 10
Roadmap

Traction first, depth in the open.

Phase 1Landing + interactive demo — live● live
Phase 2Inspector MVP — load & render .frec bundles○ planned
Phase 3Recorder MVP — real capture via instrumentation.ts○ planned
Phase 4Cache semantics + benchmarks○ planned
Phase 5VS Code ext, MCP server, AI insights○ planned
Phase 6Cloud sync, browser/desktop, Remix/SvelteKit○ planned
08 / 10
Business model

Open-core. Free to adopt, paid to collaborate.

Free$0

Local capture, all six planes, .frec, inspector. The adoption engine.

Growth$299/mo

Cloud sync, shared trace links, retention, MCP server, AI insights.

EnterpriseCustom

SSO/SAML, self-host, audit, residency, SLA.

The moat is the trace format, the reconciliation/semantics engine, and the ecosystem (MCP, editor, CI) — not the UI. Viral loop: shared trace links pull teammates in.

09 / 10
The ask

Help us give the App Router its Redux DevTools moment.

We're building Flightrec in the open. Star the repo, try the demo, and follow the build.

10 / 10