I built a $100,000 AI startup, here’s what i learned
Based on David Ondrej's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.
Start with real customer problems, ideally ones the founder personally understands, and spend at least a month validating the idea before building.
Briefing
Building an AI startup isn’t a matter of prompts or promotion—it’s a matter of picking the right problem and fixing the retention bottleneck fast enough to keep revenue from evaporating. After starting from zero and reaching roughly $10,000–$13,000 in monthly recurring revenue (MRR) at peak, David Ondrej credits the turnaround less to “fancier AI” and more to diagnosing churn and then prioritizing the unglamorous product fundamentals users expect.
The core lesson starts with idea selection. Ondrej recommends spending at least a month—longer if the goal is a decade—brainstorming problems first, then generating solutions, rather than reverse-engineering a problem to match a preconceived idea. The best target is a real, painful issue, ideally one the founder personally experiences, and the customer base should be wealthy or employed/tech-savvy so the business can sustain itself. He frames this as both art and science, but insists that solving a real problem matters more than any audience size.
That claim is reinforced with his own early numbers. Even with a waiting list of about 4,000 people and heavy promotion, he couldn’t push Vectal past roughly $2,000 MRR. The shift came after identifying the actual constraint: retention. Users were dropping off because the landing page failed to get people into the app, the in-app experience wasn’t intuitive, and there wasn’t a compelling reason to convert from free to paid. The takeaway is blunt: promotion can’t substitute for product-market fit. If churn stays high, even a viral feature that spikes signups or MRR will be lost within months.
From there, the playbook becomes operational. Ondrej draws a line between “viral features” (the unique AI hooks that attract attention) and “retention features” (UI/UX, team plans, mobile apps—capabilities users expect). The decision of what to build depends on measurement: churn, conversion rate, free-to-paid conversion, onboarding drop-off, landing-page traffic, and related funnel metrics. When retention is the problem, adding only viral features is a costly mistake.
He also argues that startups can’t be run as passive income. Building Vectal required restructuring time, canceling other commitments, and treating the work as full-time. For execution, he describes using two AI tools in parallel: one as an adviser/consultant for planning and decision-making, and another as a coding agent for implementation (he mentions Claude earlier, then switches to “CH GBT3”/ChatGPT-3 in his updated setup). Scaling, he says, depends on workload management once hiring begins—clear ownership, frequent check-ins, and avoiding ambiguous task assignments.
Finally, he emphasizes “vibe learning”: when AI can’t solve a stubborn bug, founders must get hands-on—replicate the error, inspect code, add comments, and learn through the failure. He also urges daily customer contact (he used a Discord server) to prioritize fixes and features based on real requests rather than guesswork. UI simplicity matters, and he recommends borrowing patterns from proven products like OpenAI and Apple instead of over-designing early. The closing message is iterative urgency: start now, run many iterations, and don’t quit—because readiness rarely arrives and the only reliable path is to begin and keep going.
Cornell Notes
The central finding is that AI startups scale only when the founder identifies the real bottleneck—often retention/churn—and builds the product fundamentals that keep users from leaving. Ondrej says idea selection should start from real problems (ideally the founder’s own), not from a solution looking for a market. He distinguishes viral features from retention features: unique AI hooks can attract users, but UI/UX, onboarding, conversion paths, and expected capabilities like team plans and mobile access determine whether revenue sticks. Measurement drives prioritization through churn, conversion, onboarding drop-offs, and free-to-paid rates. He also stresses full-time effort, daily customer feedback, hands-on debugging (“vibe learning”), and fast iteration over waiting for perfect readiness.
How does Ondrej decide what to build first—viral features or retention features?
Why did Vectal stall around $2,000 MRR despite a large waitlist and promotion?
What does “you cannot promote your way into product market fit” mean in practice?
What is “vibe learning,” and why does it matter when AI tools fail?
How should founders use customer feedback to prioritize work?
What’s the recommended approach to UI/UX early on?
Review Questions
- What specific metrics should a founder track to determine whether viral features or retention features should come first?
- Describe the difference between viral features and retention features, and explain why focusing on only one can fail.
- In Ondrej’s framework, what steps should a founder take when AI tools can’t fix a difficult bug?
Key Points
- 1
Start with real customer problems, ideally ones the founder personally understands, and spend at least a month validating the idea before building.
- 2
Separate “viral features” from “retention features”; prioritize retention when churn is high, even if the product has impressive AI capabilities.
- 3
Use funnel metrics—churn, conversion rate, free-to-paid conversion, onboarding drop-offs, and landing-page performance—to identify the biggest bottleneck.
- 4
Promotion can’t replace product-market fit; if users churn quickly, revenue spikes won’t last.
- 5
Treat startup building as full-time work, restructure time accordingly, and set a culture early as hiring begins.
- 6
Adopt “vibe learning”: when AI can’t solve an error, replicate it, inspect code, test, and learn by doing rather than delegating blindly.
- 7
Talk to users every day and prioritize based on real requests plus internal metrics; keep UI simple and avoid unnecessary design overhead early.