By playing, you agree to uListen's Terms and Privacy Policy and YouTube's Terms of Service.

Lenny's Podcast

Anton Osika: How Lovable scaled to 10M ARR with 15 people

Through clear, specific prompts and relentless reliability work; Lovable grew to 10M ARR mostly from people sharing demos, not from paid acquisition.

Anton OsikaguestLenny Rachitskyhost

Mar 9, 20251h 9mWatch on YouTube ↗

Summaries, chapters, transcripts, and FAQs on this page are made by uListen, not YouTube.

CHAPTERS

Jump to publisher timestamps

Chapter summaries

What Lovable is: a personal AI software engineer for the 99%
Anton explains Lovable as an AI software engineer that turns plain-English ideas into working products. The focus is enabling non-coders—founders, designers, PMs—to ship real software without the traditional engineering bottleneck.
- •Lovable turns an idea into a fully working app you can iterate on
- •Built primarily for non-technical builders ("my mom doesn't code")
- •Goal is to remove software engineering as the gating factor for entrepreneurship
- •Developers also use it to build faster, but democratization is the mission
Early traction and the “last piece of software” framing
Lenny and Anton cover astonishing early metrics and Lovable’s positioning: “the last piece of software.” Anton shares user and paying-customer counts and notes growth is largely organic despite significant internal rewrites.
- •Lovable described as “the last piece of software” that builds future software
- •Early scale: hundreds of thousands of MAUs and tens of thousands of paying users
- •ARR milestones (4M in 4 weeks; 10M in ~2 months) referenced
- •Growth driven mostly by word of mouth
- •Team had to rewrite major parts for performance while scaling
Who’s building on Lovable already (and where to see examples)
Anton gives concrete examples of users turning Lovable outputs into real client work and even startups. He points to a showcase site where built-with-Lovable apps are featured.
- •Designers shipping real web apps to clients instead of just mockups
- •Example: a photo-library categorization product launched on Product Hunt
- •Lovable-powered project showcase at launched.lovable.app
- •Signals early ecosystem formation beyond prototyping
Live demo, part 1: “Airbnb clone” in one prompt
Anton demonstrates Lovable by prompting only “Airbnb clone” and getting a polished, interactive UI quickly. They discuss how fast first-pass generation is and why this changes the cost/time equation of prototyping.
- •Two-word prompt generates an Airbnb-like interface
- •First prompt generation takes ~30 seconds
- •Output is a working site, not just static design
- •Demonstrates the leap from weeks/costly prototypes to minutes
Live demo, part 2: iterating features + the PM skill of clarity
They try adding a “purchase listing” flow; the AI interprets it as “book now,” revealing the importance of precise requirements. This becomes a discussion about prompting quality and clear communication as a core skill.
- •Feature request misinterpreted: “purchase” becomes booking flow
- •Iteration is fast, but clarity matters more than ever
- •Explaining what you expect vs. what happened is key to progress
- •AI tooling makes miscommunication cheaper than with humans
Lovable’s standout workflow: visual edits, then backend + one-click deploy
Anton shows a major differentiator: directly editing UI text visually (Wix/Squarespace-like) and having it update the underlying code. He also explains connecting a backend (Supabase) and deployment hosting (Cloudflare) for real functionality.
- •Visual editing of generated UI without re-prompting the agent
- •Edits propagate “deep down” into the codebase instantly
- •Backend connection via Supabase for auth/data persistence
- •Apps can be one-click deployed; hosting via Cloudflare
- •Path from UI mock to full app: add login, editable listings, payments, etc.
Mastering Lovable: patience, curiosity, and using Chat Mode to learn engineering
Anton’s top guidance is to treat Lovable as both a building tool and a tutor. He stresses patience, curiosity, and using chat features to understand what’s happening—plus a discipline of being specific about what’s broken.
- •Mastery requires patience and curiosity, not just prompts
- •Chat Mode helps users diagnose issues and learn how software works
- •Avoid vague feedback (“it doesn’t work”); describe exact expectations vs. reality
- •Prompting is a product-management-like skill that compounds
Origin story: GPT Engineer → Lovable for non-coders
Anton traces Lovable’s roots to an open-source experiment, GPT Engineer, created to prove LLMs could generate working code from instructions. The broader motivation became enabling anyone—not just engineers—to turn ideas into businesses.
- •Built GPT Engineer to demonstrate instruction-to-app generation
- •Open-source project achieved massive traction (stars, references)
- •Lovable created to move from developer demo to non-technical product
- •Mission: expand entrepreneurship by removing engineering as a bottleneck
Scaling laws: how they reduce “AI gets stuck” failure modes
Anton explains a key internal insight: improving reliability by identifying where the system gets stuck and tuning it quantitatively with fast feedback loops. They discuss common stuck states (bugs the model can’t unwind) and how Lovable targets critical workflows first.
- •AI builders often start strong then get stuck on bugs or dead ends
- •Lovable targets high-value flows (auth, persistence, Stripe) to avoid stalls
- •Approach: find stuck points, measure them, iterate quickly
- •Frontier of “unsticking” is receding as systems improve
Why growth is so fast with so few people: packaging + building in public
Anton attributes growth to product love and smart packaging of foundation models into a seamless UX for non-technical users. Awareness comes largely from shipping updates publicly on social media, plus a strong team taste for simplicity and abstractions.
- •Foundation models are the “oil”; Lovable’s value is the interface/packaging
- •Seamless workflows (e.g., auth integration) increase perceived magic
- •Growth driven by users loving it and word-of-mouth sharing
- •Building in public: consistently posting what shipped
- •Team emphasis: taste, simplicity, fast shipping
How Lovable differs from Bolt/Replit: reliability, visual edits, and GitHub sync
Anton positions Lovable around non-technical usability, fast visual edits, and collaboration with technical teammates. GitHub synchronization enables a hybrid workflow where engineers can drop into tools like Cursor while others stay in Lovable.
- •Differentiator: non-technical-first packaging and UX
- •Instant visual edits vs. waiting for agent changes
- •GitHub sync enables team workflows and handoffs to Cursor
- •Reliability and “not getting stuck” as a primary competitive edge
Vision and skills shift: from coding to taste, problem selection, and generalists
They explore where Lovable is headed: instant end-to-end building, deeper integrations, and even AI-driven analytics and automated experimentation. The conversation shifts to how skills evolve—discovery, taste, and cross-functional generalism rising in importance.
- •Long-term: near-instant creation integrated with existing systems/providers
- •AI can analyze user behavior at scale and propose product improvements
- •Potential for automated A/B tests and continuous optimization loops
- •More valuable skills: problem selection, user intuition, taste/quality judgment
- •Engineers evolve toward translation/constraints thinking; generalists gain leverage
Hiring and team dynamics: obsession, superpowers, and work trials
Anton outlines what he looks for in hires: deep care, team contribution, and at least one standout “superpower,” often in extracting performance from LLMs. Interviewing includes past work deep-dives, unorthodox problem solving, and unusually long work simulations.
- •Core trait: care/obsession for product, users, and team effectiveness
- •Generalist mindset plus one exceptional strength (often AI/LLM systems)
- •Hiring signals: candidates’ prior work shows depth and ownership
- •Assessment: hard novel problems + 1-day to 1-week work trials
- •Small team reality: majority still write code; roles are fluid (even content creation)
Operating model: Europe advantage, prioritization, tools, and moving fast (including lunch)
Anton discusses building in Sweden/Europe, where raw talent is strong but high ambition is rarer—creating an edge if you can attract mission-driven people. He explains a simple prioritization algorithm (biggest bottleneck first), weekly planning/demos, a short roadmap, and a lightweight toolset (Linear + FigJam) plus in-office bandwidth.
- •Europe/Sweden: lower average ambition but strong available talent; advantage if filtered well
- •Prioritization: identify biggest bottleneck, solve it hard, repeat—avoid long roadmaps
- •Cadence: weekly planning, weekly demos; occasional “polish week”
- •Tools: Linear (even for hiring tracking), FigJam for problem ranking/roadmap
- •Speed enablers: office-first, high-bandwidth communication, and shared lunches
What’s next + limitations today: more agentic workflows, domains/collab, and codebase import
Anton previews upcoming work: making Lovable more agentic (write/run tests, fix failures), adding custom domains and collaboration, and helping founders with distribution. He clarifies current limits: Lovable can’t yet fully operate on arbitrary existing codebases, though import is in research preview.
- •Agentic roadmap: system decides next steps, runs tests, debugs autonomously
- •Near-term product features: custom domains, collaboration
- •Founder support beyond build: playbooks for growth, feedback, getting users
- •Clarification: not yet usable on any existing codebase; import is early/research
- •Workflow today: start in Lovable, then engineers can work via GitHub/Cursor
Failure Corner + closing advice: start end-to-end, and become top 1% by building for a week
Anton shares a lesson from Sana Labs: retrofitting AI via an API into existing products is hard; start with the end-to-end user experience, then add AI to specific problems. He closes with concrete advice: spend a focused week using AI tools to reach a real outcome, ask questions relentlessly, and surround yourself with others doing the same.
- •Failure lesson: AI API platform was hard to adopt because it required retrofitting
- •Best practice: design the end-to-end product experience first, then add AI where it helps
- •Idea: “Lenny Mode” as a built-in PM coach to force clearer thinking
- •Heuristic: a full week building toward a real outcome puts you in the global top 1% of AI tool users
- •Use Chat/Claude/ChatGPT to learn continuously; follow Lovable channels and share feedback

Publisher timestamps

Get more out of YouTube videos.

Read along on your phone, search it beside the video, or ask your favorite AI app what was said.