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.
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.
screenshot library
The app, screen by screen
Click any screenshot to enlarge. Full-resolution files are in the
screenshots/ folder alongside this page.
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.
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.