Session 4: How to Build Micro Prototypes

A micro prototype is the smallest thing that can generate real evidence: a working app around one idea, built in a vibe-coding tool in an evening, published with one click, and put in front of a handful of real users. The discipline is in what you DON'T do — no sign-up gates (friction kills test feedback; add auth only if your data is precious enough to be scraped), no serious infrastructure, no polishing before anyone cares. Share the link, call your testers (they won't open it otherwise), and listen for the tell: 'this is interesting — I want to show my manager' means you've hit something.

The session's positioning upgrade: people sell cheat sheets and guides, but those are too cheap; DATA is a moat. Both demo archetypes — the directory app and the book-to-app — are micro prototypes wrapped around an asset (a dataset, a framework corpus) that competitors can't trivially copy. Positive feedback triggers the graduation: rebuild seriously in Codex/Claude Code, or hire the engineer, knowing demand exists.

A directory app puts a search-filter-detail front end on a dataset people need: think marketplace without the payments (or with them — Amazon is a directory plus an ordering engine). The demo dataset earns its keep twice: first by selection (YC-backed startups are pre-filtered quality that VCs literally chase — Bessemer pitched him this exact app), then by enrichment — the scraped company list was augmented with industry, AI/non-AI, business model, founders with LinkedIn profiles, team size, location, socials, and founder highlights. That structure is what made the one-shot app instantly useful: every enriched column became a filter, a tag, or a detail-page section without being asked.

The generalization is the assignment: everyone has or can build a candidate dataset — the cohort volunteered theirs live (H1B lottery data, fuel prices, genetic datasets, recruiter contact books). The formula prices itself: data quality × enrichment depth × audience desperation. A Europe-only slice of the YC data alone is sellable to European VCs at subscription prices.

Three sources feed directory apps. Your own records: contacts, transactions, niche knowledge accumulated in any career. Open repositories: biomedical, genomics, drug-discovery data linked from research papers (papers double as quality signals — cited datasets are vetted datasets). And scraping, done sensibly. The discovery move is a prompt: ask for 20 niche categories of unique data repositories with 10 links each — 200 candidates in one shot — then have AI evaluate them down to your top ten.

The twist that turns sourcing into a business: open data is always ugly. That ugliness is a moat for whoever cleans it — collect the messy corpus, have Codex study it ('propose the structure; what cleaning steps does this need?' — understanding the data is itself the task), let it write the pandas scripts, and you own a clean asset others don't. His friend runs this as a pure business: partnering with companies to strip PII from their internal corpora and selling the cleaned data to OpenAI and Anthropic. One boundary: genuinely private data never goes through Lovable or cloud APIs — that's the self-hosted Ollama-on-a-VPS lane.

The build prompt is worth studying for what it omits. It attaches the CSV, explains what the dataset IS (YC companies, what the fields mean), and describes user experience: analyze the data, build a structure to browse companies, click into details, filter by industry, B2B-vs-B2C, founder type. No model named, no database chosen, no schema designed — Lovable's platform picked the entire architecture, wired its own cloud services, and delivered the working app. That's the vibe-platform contract: you supply intent and data; it supplies engineering.

The one discipline he layers on: plan mode. First build of any project, and every new feature on an existing one, runs as a plan he reviews before implementation — the cheap checkpoint that catches misunderstandings before they're built. The flow ports everywhere (Bolt, Replit, Emergent, AI Studio, Base44); in Codex/Claude Code the same prompt works but expects you to answer a few setup questions the platforms hide.

Once the marketplace worked, one prompt added the second mode: an AI assistant behind a toggle, styled explicitly 'like claude.ai or chatgpt.com — simple, clear interface,' that takes natural-language queries ('show me AI fintech B2B companies'; 'companies from the UK'), searches the dataset, and answers. Behind the scenes Lovable Cloud silently supplied the LLM, the database, the secrets management — no API key was pasted, no model was chosen. That invisibility is the product being paid for, and also the dependency being accepted.

The iteration that followed is the transferable craft: the first assistant answered in plain text — technically correct, experientially wrong. The fix prompt specified response FORMAT: when the AI mentions a company, render its card, linking to the detail page the marketplace already built. Mode two doesn't duplicate mode one — it reuses it as the render layer. That's the two-mode pattern: structure for browsers, conversation for askers, one dataset underneath.

The insight: framework books ($100M Offers, The Intelligent Investor) contain evaluative machinery that readers never operationalize. The app version applies the machinery for them — paste your website or describe your business, get a 10-point audit where every point cites the framework it invokes ('per the value equation, your time-delay story is weak'). The rubric requirement is what makes it feel like a product instead of a chatbot: structured, cited, repeatable. The demo branded it perfectly: 'is your offer a Grand Slam or a swing and a miss?'

The business wrapper is the lead magnet: like every images-to-PDF tool that converts free and gates the download, the first audit is free and the full report costs a sign-up. The persona variant scales the pattern — Ben Graham or Buffett 'evaluating your portfolio' is the same architecture with a methodology-loaded system prompt per persona. And the copyright caveat is stated, not dodged: James Clear app-ified his OWN book; using someone else's means solving the rights question — a business problem, handled smartly, before scale.

The build-up starts from what everyone knows: saving document versions, Google Docs history. Code needs the same thing but harder — an app is dozens of files whose states must match, so the checkpoint has to snapshot the ENTIRE codebase at once. That snapshot is a commit. The software that takes and manages snapshots is Git — installed once on your machine, then operated entirely by your agent ('enable git in this project'; 'commit and push'). And GitHub is Git's Google Drive: every app is a repository (visibility private, like Doc sharing), accessible from any machine, safe when your laptop dies — 'your local system is no longer a bottleneck.'

The working vocabulary is tiny: push (upload — the agent commits automatically first), clone (download a repo to a new machine), and the rollback pair ('list all commits with their changes' → 'take me back to this one', demonstrated live with the site visibly reverting). The governance rule that prevents three-tool chaos: GitHub is the ONLY source of truth — Lovable, local and Codex all sync through it, never around it. Branches and the add/commit/push ceremony get their own session; daily work needs only 'push.'

Two routes bring a Lovable project home. The integration route (most users): connect Lovable to a GitHub repo you created, let it push, then clone locally. The download route (demoed, since his business account blocked the integration): download the code zip, unzip, open the folder as a Codex project, and prompt 'enable git and push the entire codebase to this repository.' First-time speed bumps are expected — Git install, GitHub authentication, an execution-policy confirmation on the push — each one a one-time toll.

Then the revelation: local development recreates the Lovable experience. 'Run the app for me and keep the server running' produces a localhost URL in Codex's in-app browser — chat on the left, live preview on the right, prompts queueable. The one honest asterisk: Lovable Cloud's invisible back end (database, AI model, secrets) does not travel in the zip. Static sites and front ends port perfectly; AI-dependent prototypes should stay on Lovable until the build phase teaches local equivalents.

The setup is a handshake: Vercel account, Add New Project, Import Git Repository — with the one predictable stumble being GitHub-app permissions ('could not access the repo' means grant access to that repository, not that anything's broken). Deploy, and the app is live on a Vercel URL with a generous free tier. Custom domains attach in the Domains tab, which walks the DNS changes step-by-step against GoDaddy or wherever the domain lives — his own agency site runs exactly this stack.

What makes the architecture elegant is what disappears afterward: you never visit GitHub or Vercel again. Work in Codex, test locally, say 'push' — GitHub receives the commit, Vercel detects it, redeploys (19 seconds in the live demo), and emails you if a build ever fails. The infrastructure becomes ambient. Netlify and Cloudflare Pages offer the same contract if Vercel ever disappoints.

The Lovable verdict is phase-dependent, not absolute. It's genuinely worth paying for when speed-to-test dominates: founders without time, PMs building clickable flow mockups for their engineers, anyone testing an AI feature who doesn't want to touch databases or model config — and if a $25/month app is live and collecting subscriptions, that's a fine business. It breaks at sustained building: his two days of serious work (20 hours) consumed the month's credits; at his current multi-project pace 'Lovable's bill would be at least a thousand dollars' against Codex's flat $100 — with multiple windows running four apps at once. One nuance credits the platforms: their better landing-page first-shots aren't magic — design skills are pre-baked and they always run top models, which a configured Codex matches.

The deeper economics lesson generalizes past platforms: AI features carry per-use costs that subscriptions don't naturally cover. His refusal to publish the demo app ('you'd spend all my tokens') was the lesson live. The rule: before adding AI to any app, price it from unit economics — cost per interaction, margin per interaction, expected volume — and if the answer is '$1.10 per $1.00 of credits,' the feature has no business model. Niche pricing power or funding are the outs; 'it would be cool' is not.

After three hours of proving anyone can build, the closing question — how long from prototype to revenue? — got the honest inversion: building is now the easy part; distribution is the journey. The painful stage is strategizing the go-to-market: what business model, which acquisition channels, what action plan — the phase that 'makes you doubt yourself.' The mitigations are familiar from Sessions 1-2 but land harder here: B2B moves on warm intros (one introduction to the right group outweighs months of cold outreach), and 'if the app is too good it will automatically fly — but even then, you strategize.'

The idea-sourcing habit completes the loop: keep your radar on virality. Anything blowing up on Instagram or TikTok is an app candidate — his swipe-a-dish demo (Tinder mechanics for dinner; right-swipe adds the ingredients to your cart or finds the restaurant) exists because a reel suggested it would make viral content. Build fast, attach to attention, plan distribution from day one. The full GTM playbooks — affiliate, B2B/B2C strategies — arrive after the cohort has things worth distributing.