Flowwright 2.0 — AI Browser Automation Studio

Problem

Browser automation is easy to fake with static wireframes. Recruiters and clients need to see plans, runners, logs, and artifacts working together—the same primitives you would operate in production (Playwright workers, queues, retries, exports).

Why I built it

I wanted a single surface that tells a credible story: translate intent, let humans adjust steps, execute with transparent telemetry, and land structured outputs suitable for downstream systems. The UI is the product—there is no unrelated entity admin or ticket queue stealing attention.

System architecture

• Presentation — Next.js App Router, a studio layout with Visual vs Developer mode, plus specialized panels (browser preview, step inspector, preflight quality, run summary) instead of generic admin tables.
• Preflight — planValidation.ts scores the plan for navigation/extract/retry/safety so the product reads like an engineering release gate.
• Planning layer — planGenerator.ts fronts a deterministic mock (mockPlanGenerator.ts); a real LLM can slot in behind the same interface.
• Preview mapping — browserPreviewStates.ts translates the active step + scenario into chrome-level UI: URL bar, hot highlights, wait spinners, extract cards, capture flash—clarifying the worker without a headless binary in the repo.
• Execution layer — demoRunner.ts is event-driven (logs, results, progress, step patches) and supports windowed runs (start index), skipped disabled steps, and the same log schema a queue worker would emit.
• Data plane — ExtractedResult rows (with optional source step metadata) feed human review, JSON/CSV, and a developer “copy as JSON” affordance.

Natural language input
     → planGenerator
     → plan validation (readiness + policy checks)
     → visual timeline + step inspector
     → demoRunner (or future Playwright worker)
     → browser preview state
     → run log stream + screenshots
     → extracted results + run summary
     → exporters / developer JSON view

Why this is not just CRUD

CRUD is “pick an entity, edit fields, save to a table.” This product has no first-class data model in the application layer—no accounts, no tickets, no list/detail screens. The entire surface is a pipeline from intent to structured automation instructions to a simulated run to extract buffer and exports. The closest thing to “records” is the typed extraction result set, and it is intentionally ephemeral. That keeps the story honest: the skill on display is orchestration and observability, not schema wiring.

Core features (second polish pass)

• Browser preview — a simplified worker tab that animates in sync with the current step, including loading bars, type targets, wait spinners, extract highlights, and screenshot capture flash. Labeled demo everywhere so expectations stay accurate.
• Step inspector — click a timeline node to see targets, model confidence, safety context, and illustrative Playwright-style code that is not executed in this build.
• Preflight quality — a checklist + readiness score that reads like how a staff engineer would de-risk a rollout.
• Run summary — duration, warnings, retries, rows, average confidence, and available exports after a successful run.
• Developer view — raw AutomationPlan JSON, multi-tab logs / results, and full pseudo-code in one place for interview walk-throughs.
• Human review loop — extraction table with clear Accepted / review / low-confidence posture, per-row copy, and source step hints.
• Responsible automation copy and exports remain in-product, not in a side PDF.

Technical challenges

The hardest part is making a demo feel like a system: controlled timing, one meaningful retry scenario, believable extracted rows, and zero dead controls. The runner is intentionally linear and event-driven so it can be replaced with a WebSocket-backed worker later without redesigning the panels.

Safety and responsible automation

The product narrative assumes permissioned automation, respect for access controls, and synthetic fixtures for public demos. Unsafe phrasing in prompts surfaces a safety note—this is product policy, not fine print.

Future improvements

• Wire OpenAI/Anthropic for true NL→plan with schema validation.
• Attach a headless Playwright worker via queue + signed job payloads.
• Persist runs in Postgres for multi-session history (still not generic CRUD—run archive only).
• Role-based approvals for sensitive exports.

Tech stack

Next.js 15 · React 19 · TypeScript · Tailwind CSS v4 · lucide-react · deterministic demo automation libs under src/lib/automation.