Product Case Study · 2026

VibeForge: an interview becomes a build-ready spec.

$ 30 questions in, 14 documents out.

VibeForge was a production SaaS built around a general-purpose AI-assisted interview engine. A flow — pure JSON configuration — defines what to ask and which artifacts to produce; the engine supplies everything else: the guided interview UI, per-question AI suggestions, gating, and a multi-LLM draft‑critique‑polish pipeline that writes each artifact to its declared acceptance criteria. Any interview that ends in a model-assisted deliverable fits — a research brief, an RFP response, a migration plan, a client discovery questionnaire.

The two flows it shipped with were technical: Product Vision interviewed a founder the way a great PM would and forged a complete product specification — PRD, architecture, data model, API surface, test strategy, backlog, and more — zipped and delivered in about nine minutes; Feature Use Case did the same for a single feature, Cockburn-style. Designed, built, and operated solo — with AI agents as the build team — from first commit to Azure production, including auth, payments, observability, and cost telemetry. The service has since been retired; this page is its record.

2
flows shipped — engine takes any
14
documents per Vision package
~9 min
interview → zipped package
$0.53
avg LLM cost per interview
52
packages forged in production
90-second demo

See it work

A real production run, captured before retirement: choosing a flow, the guided interview with live AI suggestions, the forge pipeline streaming stage-by-stage, and the ops dashboards underneath.


the story

Why it existed

"Vibe coding" made building fast and specifying slow. Agents write code from whatever you give them — and most people give them a paragraph. VibeForge attacked the upstream problem: getting clear requirements out of someone's head and into documents an agent (or a team) can actually build from.

The bet

  • A structured interview beats a blank prompt: topics, required-question gating, and per-question AI assists produce dramatically better inputs.
  • An engine, not a wizard: interview mechanics are generic, so every domain-specific decision — questions, artifacts, prompts, acceptance criteria — lives in flow config, not code.
  • A strong model checked by a different one beats one model grading its own work: Opus 4.8 drafts and polishes, Grok 4.3 critiques in between.
  • Acceptance criteria per document, declared in config, keep 14 documents consistent with each other and with the author's exact words.

What shipped

  • The flow-agnostic engine, plus two flows as pure JSON config: Product Vision (29 questions → 14 documents) and Feature Use Case (Cockburn-style, 41 questions → 5 artifacts).
  • Adding a flow meant copying flows/_template, editing JSON, and routing users to /interview?flow=research — no engine changes.
  • Express mode, sketch upload with vision analysis, autosave/resume, showcase gallery of example outputs.
  • Google OAuth + RBAC, Stripe credit packs, admin suite: pipeline health, per-stage cost telemetry, purchases, audit log, maintenance mode.
Operating numbers, cradle to retirement: 57 interviews and 52 forged packages across 8 users; 714 LLM API calls totaling 3.9M tokens for $30.42 of model spend — $0.53 per interview on average. A typical production run: draft ≈ 3m · critique ≈ 2m · polish ≈ 2m 30s · full package ≈ 9 minutes.

how it worked

Product walkthrough

The journey below is what the engine provided to every flow, free — the shipped flows just filled in the questions and the artifact list.

1 · Choose a flow

  • The landing page listed the installed flows — Product Vision and Feature Use Case in production — each with time estimates, question counts, and example artifacts up front. A flow is a folder of JSON: topics.json (the interview), artifacts.json (the deliverables and their acceptance criteria), prompts, and schema.

2 · Guided interview

  • Topic groups with progress tracking, driven entirely by the flow's config. Required questions gate the forge; recommended ones can be skipped. Express mode trims to essentials.

3 · AI suggestions

  • Per-question suggestions from Grok fast-reasoning under a 2.5s latency budget, with deterministic fallbacks — the app stays useful even with every LLM down. Tap to accept; verbatim answers are protected through every later stage.

4 · Enter the forge

  • One click queues an async job on Azure Queue Storage. A live terminal streams each stage: Draft (Opus) → Critique (Grok) → Polish (Opus) → Package. The flow's declared artifacts — fourteen for Product Vision — land as a zip with Markdown, Mermaid diagrams, and Gherkin tests.
An engine, not a wizard. Nothing about PRDs is hardcoded. The interview UI, AI suggestions, gating, pipeline, packaging, credits, and ops all live in the engine; the two shipped flows just happened to be about software. The same deployment could have run a market-research interview producing a research brief, or a vendor interview producing an RFP response — by adding a folder of JSON.


under the hood

The machinery

The full interactive engineering deep-dive — flow engine, pipeline, internals, and Azure architecture — is preserved exactly as it shipped in production.

Open "Under the Hood" →
stack
Next.js 15 · App RouterReact 19Prisma + PostgreSQL Flexible Server Azure Container AppsBlob + Queue StorageKey Vault · private endpoints VNet · managed identityBicep IaCGitHub Actions · OIDC App Insights + OpenTelemetryUpstash Redis rate limiting Auth.js v5 · Google OAuth · RBACStripe Checkout + webhooks Opus 4.8 · Grok 4.3 · Gemini 3.1 · GPT-5.5 (tiered fallback)
Resilience by design: every LLM stage had a deterministic fallback, packages fell back to base64 delivery if Blob storage failed, rate limiting degraded from Redis to in-memory, and the queue worker recovered dead-lettered jobs without double-charging credits.