Build Log 02 — Vibecoding as a PM: what I built, what broke, what I'd do differently

TL;DR

Most product failures stem from activation gaps rather than feature deficiencies. Building an AI prototype for aiEDU to address one specific activation problem showed that product decisions — not code quality — determine success. The bugs that mattered most got turned into permanent system rules.

Live demo · GitHub source

The problem

aiEDU's gallery of educator-built AI tools breaks at a critical moment. Educators browse, feel inspired to create, but by the time they navigate to the generic build page, the momentum disappears. Inspiration is perishable.

The hypothesis

Closing the navigation gap and providing contextual prompts within the gallery itself — triggered at the moment of genuine intent — would increase actual build attempts.

Pre-development decisions that endured

Before coding, testing the brief itself yielded two foundational choices:

North star metric: rather than tracking gallery submissions (too many variables), the measure was immediate behavior — whether educators clicked "Build" after viewing a generated prompt.

Trigger selection: a 45-second dwell timer felt like a disguised popup. Card-close became the trigger instead, representing genuine intent. A timer interrupts before the user signals anything.

Product decisions that held

The system prompt matters more than the interface. Early onboarding asked about project scope ("quick tool" vs. longer-term), but this contradicted the platform's core thesis and created escape hatches for uncertainty. Output type proved more honest and actionable.

The generated prompt quality remains the riskiest assumption: whether any of this works comes down to one thing — is the generated prompt good enough that an educator clicks Build?

AI's role across all phases

Claude participated in discovery, specification, build, and debugging. A key contribution: flagging that timer-based triggers are behaviorally equivalent to popups, which shifted the specification before implementation.

Converting every bug into a permanent rule created a compounding system: don't just fix the bug, upgrade the system that produces bugs.

Critical bugs and lessons

• API documentation drift: switching from Anthropic to Gemini updated the code but not the docs. Fix: update all references in one commit.
• Model retirement silence: gemini-2.0-flash's free tier disappeared mid-build with no error message. Fix: pin model names with verification dates.
• HTTPS popup blocking: window.open() worked on localhost but was blocked in production. Native anchors are trusted everywhere and right-clickable.
• SessionStorage isolation: new tabs lack access to parent tab storage. Fix: encode prompts as URL query parameters.

Deliberately out of scope

Auth, databases, saved history, A/B infrastructure, and live embedding were excluded intentionally. PostHog analytics are wired correctly but not yet activated — analytics infrastructure before you have users is premature optimization.

What would change

Testing on production-equivalent origins earlier would have caught the HTTPS and storage bugs immediately. Parallel validation of the system prompt — testing multiple educator inputs — should run alongside implementation, not afterward.

What actually got proven

The prototype demonstrates buildability at appropriate fidelity, not hypothesis validation. That requires real educators, production triggers, and actual behavior data. The remaining question is still: is the generated prompt good enough?