I Built Multiple AI MVPs — My Biggest Mistakes

Problem

I could spin up AI demos quickly — Cursor + a model API + a thin UI — but I kept confusing demo velocity with product learning. Several MVPs later, the same failure modes kept showing up: unclear jobs, chat boxes pretending to be products, and surprise invoices.

This is a cross-cutting build-in-public post. Counts and revenue stay as placeholders until I publish verified numbers.

Why I built it

Not one product — a pattern. I wanted a public autopsy so the next MVP (and readers building theirs) skips the expensive lessons. Related deep-dives: parenting copilot and cost control before launch.

Initial hypothesis

Across early projects I believed some mix of:

1. “If the model is impressive in a Loom, distribution will follow.”
2. “A general assistant with light branding is an MVP.”
3. “I can add auth, RLS, and spend caps after a few users care.”

Those hypotheses were wrong often enough to write this post.

MVP

What “MVP” meant in practice for me (and where it went sideways):

• Landing page + waitlist + core generation loop
• Sometimes billing wired before retention was understood
• Sometimes the opposite: polish on prompts with no path to a repeatable workflow

A healthier MVP definition I use now: one user, one job, one measurable success event, cost-capped path, private data boundary.

Technology stack

Common stack across experiments:

• Next.js / Vercel
• Supabase or similar for auth + data
• Server-side model calls
• Cursor as the primary build environment

The stack was rarely the bottleneck. Product honesty was.

AI architecture

Mistakes clustered here:

• Chat-shaped everything — unbounded turns, unbounded context
• No prompt/model versioning — could not explain regressions
• Evals = vibes — I tested on three friendly examples and shipped
• Tools/agents too early — multi-step loops before a single-step job worked
• Logging prompts without a retention story — privacy debt

The architecture that eventually felt sane: structured input → single server action → capped generation → persisted result + versions → optional narrow follow-up.

What worked

• Killing ideas after a week when I could not state the job in one sentence
• Structured forms over empty chat for vertical MVPs
• Reusing the same production checklist mindset from prototype to production
• Writing build-in-public notes while mistakes were fresh

What didn’t

1. Fuzzy JTBD — “AI for X professionals” without a weekly ritual to attach to
2. Premature multi-tenancy theatre — teams features before solo value
3. Late metering — learning that a feature was unprofitable after sharing links
4. Marketing before instrumentation — posts that drove curiosity I could not measure
5. Treating model upgrades as free quality — silent prompt breakage

Cost lessons

• Unit cost belongs next to the user story, not in a month-end panic
• Cheapest mistake prevention: max tokens, per-user daily caps, and a kill switch
• “I’ll optimise prompts later” often meant “I’ll pay for verbose system prompts forever”

User feedback

Patterns (qualitative, not a fake NPS table):

• Users asked “what should I paste?” more than “what model is this?”
• Trust rose when the product showed sources or the user’s own prior inputs
• People abandoned open-ended chat that required prompt engineering skill

Still unfilled on purpose:

What I would change

If I restart any AI MVP tomorrow:

1. Write the success event and non-goals before opening Cursor
2. Instrument cost and activation on day one
3. Ship one workflow, not a platform
4. Budget an eval set (even 20 examples) before public links
5. Delay distribution until the kill switch and caps exist

Next experiment

Take a single MVP and run a constrained cohort with pre-registered metrics:

• Activation = completed primary job once
• Return = second session in 7 days
• Cost = p50 / p95 cost per activation