Liaison

• 

  The client can answer asynchronously and bring the project scope back into alignment

Why I built it

Software projects often drift because the client’s goals live in chat, engineering constraints live in private notes, and the shared product brief falls behind both. The problem is rarely that nobody communicated. It is that important questions, trade-offs, and approvals become scattered across different conversations.

I built Liaison to make those conversations easier to follow and harder to lose.

What it does

Liaison gives clients and developers a shared product-discovery workspace while preserving the boundaries each side needs.

A client is guided through a structured discovery interview. As they answer, Liaison updates the shared product brief and identifies possible requirements, scope changes, user stories, and milestones. Factual details can be recorded immediately, but proposed scope stays pending until the client approves it.

Developers can read the client’s original conversation and work in a private technical area for feasibility, architecture, risks, and engineering decisions. When a technical trade-off needs to be explained, Liaison turns the developer’s shorthand into a clear client-facing update. The developer reviews and publishes that translation before the client sees it.

The result is a durable record of what was discussed, what changed, who approved it, and why.

The included demo follows an invoice-portal project from client discovery through developer review and final client approval. It runs without credentials so judges can replay the full workflow reliably.

How I built it

Liaison is built with Astro, React, TypeScript, Tailwind CSS, Cloudflare Workers, Supabase, and Gemini.

The product has two paths:

• A deterministic browser-local demo with versioned state and no secrets.
• A production path using Supabase authentication, Postgres, Row Level Security, and a server-side AI provider.

Shared and private project data are separated by role. Model output is validated before persistence, document changes use version checks, and important AI output remains a draft or suggestion until the appropriate person acts on it.

The live AI path currently uses Gemini behind a provider-neutral contract. That keeps product rules and authorization separate from any one model provider.

How Codex and GPT-5.6 helped

I used Codex with GPT-5.6 as my implementation partner throughout the build. It helped me turn the original product idea into concrete user journeys, permission boundaries, architecture, typed interfaces, database policies, tests, and a deployable Cloudflare application.

Codex also helped debug the less glamorous but essential parts of the alpha: shared-database migration naming, Supabase Row Level Security, invitation flows, browser-specific errors, responsive workspace navigation, production secrets, and the judge-only deployment.

GPT-5.6 was used during the build process. It is not presented as Liaison’s production runtime model; the deployed live adapter currently uses Gemini.

What I learned

The most important design decision was that Liaison should not act like an autonomous product manager. Its value comes from keeping context connected while making responsibility clearer. Developers still decide what gets published, and clients still decide what changes the agreed product scope.

What’s next

The next major mode is a consent-first Meeting Observer. Liaison would capture notes from direct client-developer meetings, connect them to the existing project record, and prepare proposed documentation updates for review. Later versions could add transcripts, speaker attribution, integrations, richer revision history, and reusable discovery templates.

Built With

• astro
• cloudflare-workers
• google-gemini
• gpt-5.6
• openai-codex
• react
• supabase
• tailwind-css
• typescript