Greenlit

We help web agencies prove their work is done so clients can approve it faster. Don’t just show it. Prove it.

Comment

Inspiration

Web agencies rarely wait to invoice because the work was never completed. They wait because “done” is scattered across a statement of work, staging links, QA notes, email threads, and subjective client feedback.

Engineers know the milestone is finished, but account managers struggle to present clear proof and clients do not want to interpret test logs. The result is approval limbo, delayed invoices, and confusion about whether a request is a correction or new scope.

We built Greenlit to make the statement of work—not the test suite—the center of project acceptance.

What it does

Greenlit turns contractual promises into evidence a client can understand.

An agency can:

  1. Paste a non-confidential SOW excerpt or upload a selectable-text PDF, TXT, or Markdown file.
  2. Use Gemini to draft atomic, measurable acceptance criteria with exact supporting quotes.
  3. Edit and human-confirm every criterion before it becomes frozen scope.
  4. Map supported promises to safe, typed browser checks instead of AI-generated scripts.
  5. Verify those promises against a staging build and capture observed results.
  6. Send the client a focused, no-login review packet.
  7. Collect an approval or clearly categorized change request.
  8. Produce an invoice-ready proof record connecting the SOW revision, build, evidence, decision, timestamp, and milestone value.

Our demo includes a deliberately deceptive failure: a contact form visually reports success while its API request returns HTTP 500. Greenlit catches the contradiction and then verifies the corrected build against the same frozen scope.

For custom projects, an agency must prove control of the staging hostname and explicitly configure each supported check. Greenlit never presents synthetic fixture results as proof of a real customer project.

How we built it

Greenlit is a TypeScript and React application built with Next.js and deployed through Vercel.

Gemini produces structured criterion drafts using the Google GenAI SDK. Zod validates the output, while Greenlit independently checks every quoted passage against the uploaded source. AI can suggest criteria, but it cannot approve scope or generate executable browser code.

The verification system separates orchestration from execution:

  • The Next.js service validates and freezes the confirmed revision.
  • A signed request dispatches a job identifier to a Cloudflare Queue.
  • A Cloudflare Worker leases the frozen checks.
  • Cloudflare Browser Rendering and Playwright perform isolated, typed checks.
  • Results and screenshots return through an HMAC-signed callback.
  • Supabase stores project records, private evidence, review sessions, decisions, and retention metadata.

Supabase provides PostgreSQL, authentication, private storage, row-level security, review-link revocation, legal holds, and automated retention.

Security boundaries are enforced throughout the workflow. Greenlit rejects private and reserved network destinations, requires staging-origin ownership, and allows only predefined assertions using accessible labels and same-origin paths. Gemini cannot provide JavaScript, selectors, credentials, arbitrary headers, or off-origin actions.

Challenges we ran into

The hardest problem was preserving the convenience of AI without allowing AI to become the authority.

A convincing paraphrase can still change what a client signed. We therefore made exact source grounding and human confirmation mandatory. Editing a confirmed criterion automatically invalidates its confirmation until it is reviewed again.

Document extraction presented another challenge. PDF text often contains inconsistent spacing and line wrapping, so we built normalization that tolerates formatting differences without accepting invented words.

We also needed a memorable verification demo that did not overstate what had been proven. We created two controlled staging fixtures: one produces a false visual success while returning an HTTP error, and the second fixes the endpoint. Custom SOWs cannot reuse these synthetic results.

Finally, we treated the browser runner as an untrusted boundary. Queue messages contain only job identifiers, leases and callbacks are signed, execution is limited by shared schemas, and sensitive source text is excluded from verification logs.

Accomplishments that we are proud of

  • A complete agency-to-client workflow rather than a disconnected AI demonstration.
  • Live Gemini analysis with paste and PDF, TXT, and Markdown imports.
  • Independently grounded acceptance criteria with exact source citations.
  • Human confirmation gates that are invalidated after edits.
  • Safe typed browser checks instead of arbitrary generated code.
  • Staging-origin ownership verification and private-network protection.
  • Signed queue, runner, and callback architecture.
  • A visible false-success/API-failure demonstration.
  • Durable agency accounts and cross-device project history.
  • Revocable client review links and remote-decision notifications.
  • A responsive, keyboard-usable interface with reduced-motion support.
  • Printable, invoice-ready approval records.
  • Invite controls, rate limits, retention, feedback intake, and operator tooling.
  • Extensive contract, security, accessibility, unit, integration, and browser testing.
  • A deterministic synthetic walkthrough that remains available if an external service is unavailable.
  • No paid services enabled for the submission.

What we learned

AI is most trustworthy when its role is narrow, visible, and reversible.

Structured output helps, but the strongest safeguard is an independent invariant: every generated claim must point back to words the user can inspect. The agency confirms the scope, the browser records what happened, and the client makes the final decision.

We also learned that client acceptance is a translation problem as much as a testing problem. Technical results become valuable only when they are connected to the exact promise they prove.

Finally, security and honesty are part of the user experience. Clearly distinguishing retained evidence from a synthetic walkthrough makes the product more trustworthy, not less impressive.

What's next

Our next steps include:

  • Multi-user agency workspaces with role-based access.
  • Playwright and Cypress adapters that import evidence without importing arbitrary execution.
  • Change-order detection when a new SOW revision modifies frozen scope.
  • Metrics for approval-cycle time, change-request causes, and value waiting for approval.
  • Project-management and invoicing integrations.
  • Pilot programs with web agencies to measure how much approval and invoicing time Greenlit saves.

Greenlit is not a legal e-signature service, accounting ledger, payment guarantee, or formal accessibility certification. It is a proof and decision workflow designed to help agencies move completed work from staging to client approval.

Built With

Share this project:

Updates

Submission history