Project Info
Inspiration
Developers often do not find critical UI issues until after a product is already live. A form label may seem clear to the team, but confuse an ESL user. A save button may work on desktop, but fall below the fold on mobile. A privacy-sensitive user may abandon a flow because optional tracking or personal-data fields feel required. We built FlowProof to catch those issues before production. Instead of waiting for real users to struggle, FlowProof uses AI-driven personas as pre-production testers. Each persona interacts with the site differently, exposing usability, accessibility, and clarity problems while developers still have time to fix them.
What it does
FlowProof is a pre-production UI QA tool that uses AI personas to find confusing, inaccessible, or fragile user flows before real users encounter them. It lets developers test a website flow before shipping it. They define a target page, a task, and success criteria. FlowProof then runs that flow across multiple behavioral personas, such as: an impatient user who clicks the first plausible control an ESL user who prefers simple labels a mobile-first user working in a small viewport a privacy-sensitive user who rejects tracking and optional personal data an adversarial user who tries invalid inputs and unusual navigation a power user who uses shortcuts and search For each persona, FlowProof launches a browser session, attempts the task, checks whether the success criteria were met, and records what happened. The result is a developer-facing report showing: which personas passed or failed where the UI became confusing screenshots and action traces failure categories Sentry and Browserbase debugging links ranked risk areas suggested fixes for the demo flow The goal is to make UI problems visible before a page is published, not after users have already been affected.
How we built it
We built FlowProof as a Next.js app with TypeScript, React, Tailwind CSS, Prisma, and Postgres. Browserbase and Stagehand power the browser automation layer. Each test run creates a set of persona-specific test cases, executes them in browser sessions, and stores the results in Prisma. We capture screenshots, action traces, raw logs, final page state, failure reasons, and success-oracle results. Sentry is integrated so failures can be connected to trace metadata, making debugging easier for developers. For the demo, we built an intentionally tricky account settings page with common pre-launch UI problems: ambiguous email fields, vague validation, privacy friction, optional personal-data fields, and mobile visibility issues. FlowProof catches those issues, then generates a self-healing demo run that shows how the interface could be improved.
Challenges we ran into
One challenge was making the demo realistic without making it unpredictable. Real browser agents can fail for many reasons, so we created a controlled Demo-Safe mode where the UI traps and persona behaviors are understandable and repeatable. Another challenge was distinguishing actual UI failures from infrastructure failures. If Browserbase cannot reach a site, that is different from a mobile-first persona missing a hidden save button. FlowProof classifies these separately so developers know what is actually actionable. We also had to think carefully about privacy. Debugging UI failures can involve sensitive page content, so FlowProof focuses on structured traces and redacted fix context instead of blindly sharing everything.
Accomplishments we're proud of
We are proud that FlowProof feels like a real pre-production QA tool, not just a demo script. It has project configuration, seeded personas, browser execution, run history, success oracles, failure classification, screenshots, action traces, risk ranking, and a self-healing demo loop. The most exciting part is seeing a vague UI problem become concrete. Instead of saying “the page might be confusing,” FlowProof can show that the ESL persona selected the billing email field instead of the account email field, or that the mobile-first persona stopped because the save button was not visible. That turns usability feedback into something developers can actually act on before launch.
What we learned
We learned that accessibility and usability testing should include behavior, not just static checks. A page can technically contain the right elements and still fail if users cannot confidently complete the task. We also learned that traces are much more useful than pass/fail labels. When developers can see the persona rule, the chosen action, the screenshot, and the success check together, the fix becomes much clearer. Most importantly, we learned that AI agents can be valuable not only as end users of websites, but as pre-production testers that help developers improve experiences for real people.
What's next
FlowProof starts with pre-launch persona testing, but the bigger goal is continuous UX reliability. Right now, FlowProof includes a small set of built-in personas, such as mobile-first, privacy-sensitive, ESL, impatient, adversarial, and power users. Over time, we want teams to create their own personas that reflect their actual customers, accessibility needs, product domain, and support history. We want FlowProof to run automatically on every pull request, staging deploy, and production release, proving that critical flows like onboarding, checkout, account recovery, settings, and forms still work for different types of users. Long term, we imagine FlowProof connecting directly into design systems, CI pipelines, issue trackers, analytics, and code agents. Instead of waiting for users to report confusing UI, teams would get a full feedback loop: detect who is affected, diagnose where they got stuck, suggest or generate a fix, and re-test before the problem reaches production.
FlowProof
FlowProof is a pre-production UI QA tool that uses AI personas to find confusing, inaccessible, or fragile user flows before real users encounter them. Developers define a target page, task, and success criteria; FlowProof runs that flow across behavioral personas, records evidence with Browserbase/Stagehand and Sentry context, and can trigger an autofix workflow in the target website repo.
Local setup
npm install
cp .env.example .env
npm run prisma:migrate
npm run prisma:generate
npm run prisma:seed
npm run dev
FlowProof uses Prisma with Postgres. For local development, use any local or hosted Postgres database and set:
DATABASE_URL="postgresql://USER:PASSWORD@HOST:PORT/DATABASE?sslmode=require"
DIRECT_URL="postgresql://USER:PASSWORD@DIRECT_HOST:5432/DATABASE?sslmode=require"
For a fast hosted option, create a Neon or Supabase Postgres database and paste its connection strings into .env. With Supabase, use the transaction pooler connection string for DATABASE_URL. Use the direct connection string for DIRECT_URL; if Vercel cannot reach the direct host, use Supabase's session pooler connection string for DIRECT_URL.
Autofix PR flow
FlowProof does not clone or edit target website repositories. When a failed test case triggers Create Fix PR, FlowProof:
- Collects failure evidence from the TestCase, Run, Persona, Browserbase session metadata, Sentry trace metadata, and action trace.
- Redacts sensitive fields and stores a
FixAttempt. - Creates a signed fix-context URL.
- Dispatches a GitHub Actions workflow in the configured target website repo.
- Serves the signed FixContext to GitHub Actions and marks the
FixAttemptasCONTEXT_FETCHED. - Receives the GitHub Actions callback with
PR_OPENEDorFAILED, then stores the PR URL or error for the run dashboard.
Required env vars:
DATABASE_URL=
DIRECT_URL=
GITHUB_TOKEN=
FLOWPROOF_APP_URL=
FIX_CONTEXT_SECRET=
GITHUB_TOKEN should be server-only and scoped to the target website repo with permission to trigger Actions workflows.
FLOWPROOF_APP_URL must be publicly reachable by GitHub Actions. localhost will not work for the full workflow unless you use a public tunnel. Existing deployments can continue using PERSONAPROBE_APP_URL.
FIX_CONTEXT_SECRET signs fix-context URLs. Generate one with:
openssl rand -hex 32
Target repo workflow
Add a workflow like examples/flowproof-autofix.yml to the target website repo at:
.github/workflows/flowproof-autofix.yml
Then configure a Project in FlowProof with:
- target URL
- GitHub owner
- GitHub repo
- base branch
- workflow file name
The example workflow fetches the signed FixContext, commits a placeholder evidence file at flowproof-fix-evidence/<fixAttemptId>.md, opens a draft PR, and calls back to FlowProof with the PR URL. This proves the end-to-end handoff before a real coding agent is wired in.
The target repo workflow needs these permissions:
permissions:
contents: write
pull-requests: write
Autofix demo checklist
- Deploy FlowProof somewhere GitHub Actions can reach and set
FLOWPROOF_APP_URLto that public origin. - Set
DATABASE_URL,DIRECT_URL,GITHUB_TOKEN, andFIX_CONTEXT_SECRETin FlowProof. - Add
.github/workflows/flowproof-autofix.ymlto the target repo usingexamples/flowproof-autofix.yml. - Create or choose a FlowProof Project that points at the target repo and workflow file.
- Run a probe, open the run detail page, and click Create Fix PR on a failed test case.
- Watch the failed test case move through
WORKFLOW_TRIGGERED,CONTEXT_FETCHED, andPR_OPENED. The dashboard will show the draft PR link after the callback lands.
The FixContext endpoint is GET /api/fix-context/:id?token=<signed-token>. The callback endpoint is POST /api/fix-attempts/:id/callback with Authorization: Bearer <signed-token> and a JSON body like:
{
"status": "PR_OPENED",
"prUrl": "https://github.com/owner/repo/pull/123",
"githubWorkflowRunId": "1234567890",
"evidence": {
"branch": "flowproof/autofix-fixAttemptId",
"commitSha": "abc123",
"workflowRunUrl": "https://github.com/owner/repo/actions/runs/1234567890"
}
}
Deployment note
Vercel can host the Next.js app. Add DATABASE_URL and DIRECT_URL in Vercel before deploying for a working app. During npm run build, FlowProof runs prisma migrate deploy and seeds the default personas when DATABASE_URL is configured. If Supabase's direct host is unreachable from Vercel, the build script retries migrations through the Supabase session pooler derived from DATABASE_URL.
Analysis
View
Metric
- 20
Figures cover GitHub contributors during the hackathon window. A co-authored commit counts in full for each author, so per-member totals add up to more than the whole-team figures.
Technology
- CSSIn code
- Next.jsIn code
- ReactIn code
- SQLIn code
- Tailwind CSSIn code
- TypeScriptIn code
- PostgreSQLClaimed
- VercelClaimed
6 of 8 appear in the indexed code. 2 claimed on Devpost could not be matched to code, which may simply mean the tool leaves no trace in the repository.
AI coding agents
No AI coding agent signals were found in this repository.
Detected from committed agent config files and commit authorship. Absence of a signal is not proof an agent was unused.
Codebase size
Source size
264 KB
Source files
67
Counts recognized source files only; vendored directories, binaries and lockfiles are excluded, so this is smaller than the repository on disk.
Repository
pauline-ongchan/flowproof
78 files · 781 KB · @ 2040d05
Structure
Interface
18 files · 23%Screens, components and styles rendered to the user.
API & routing
10 files · 13%Request entry points: routes, handlers and controllers.
Application logic
27 files · 35%Domain rules, services and shared utilities.
Data & schema
6 files · 8%Schema definitions, migrations and data access.
Supporting
Layers are inferred from where files sit in the tree, not from reading the code. A project that names its directories unconventionally will read oddly here — open the file browser to check anything the diagram implies.
Languages
- TypeScript94%
- YAML2%
- Markdown2%
- SQL2%
- CSS0%
Share of indexed source by file size. Binary and vendored files are excluded.
Dependencies
package.json
npm · 18- @browserbasehq/stagehand
- @prisma/client
- @sentry/nextjs
- lucide-react
- next
- react
- react-dom
- +11 more
Declared in the repository’s manifests at the indexed commit. A declared package is not proof it is used, and runtime dependencies are listed first.
This project’s features have not been analysed yet.
Export this project's context (description, README, evidence, key source files) to chat with an AI agent elsewhere.