Lovable's Anton Osika on Building "the Last Piece of Software" With 18 People

Osika describes Lovable as a personal AI software engineer: you describe an idea and get a fully working product back. Entrepreneurs use it to turn ideas into businesses, designers and product managers use it to create a first version to show their teams, and developers use it to build faster.

His motivation is simple. His mother doesn't write code, and friends have always asked him how to find a good software engineer. Lovable targets that 99% of the population, and Osika expects that talking to an AI will eventually become the natural way to build software.

The scale is striking. Less than three months after launch, Osika says, Lovable had 300,000 monthly active users, 30,000 of them paying, growing almost entirely through organic word of mouth. Host Lenny Rachitsky adds that the company hit 4 million ARR in four weeks and 10 million in two months with 15 people. The team also had to rewrite its whole code base after outgrowing its first scripting-language service, pausing new features for a while.

Real companies are already starting from the tool. Osika points to an early user, Harry, who moved from shipping web apps to clients instead of designs to launching an AI startup for categorizing photo libraries. A showcase at launched.lovable.app lists other small businesses built this way.

In the live demo, Osika types just two words, "Airbnb clone", and Lovable produces a polished interface with categories, listings and login buttons. The first prompt takes about 30 seconds. It is a front-end mockup that is interactive, but without real data behind it.

When Lenny asks to add a way to buy a listing, the AI adds a button labelled "Book now" instead of "Buy now", a reminder that vague prompts yield surprises. Lenny notes this is a good case for product-management skills, since the AI doesn't need the why but needs a very clear what. Osika agrees that stating exactly what you expect, and what is not working, matters even more with AI than with humans.

Osika then shows a feature launched days earlier: visual editing, like Squarespace or Wix, where you select an element and change its text directly. The change lands deep in the code base but happens instantly. Lenny says no other tool he knows of lets you tweak a small element of AI-generated code without asking the agent and hoping for the best.

To make the app real, Lovable connects to Supabase, an open-source backend as a service, with one click, and apps deploy in one click on Cloudflare hosting. Next steps would be adding login and letting users edit and upload listings. Lenny reflects that something that once took weeks and tens of thousands of dollars to prototype now takes about five minutes.

Osika says these tools are already good and improving fast. A major remaining bottleneck is that they are not yet integrated with existing products. His advice is to get your hands dirty, because being in the top 10% of users will set people apart in the coming months and years.

His single tip for new Lovable users is curiosity and patience. He points to chat mode, where you can ask the agent how something works or what you might be missing, as both a productivity tool and a way to learn how software gets built. The second tip is to avoid saying "it doesn't work" and instead explain what you expect and which parts do and don't work.

On the name, Osika says the best word for a great product is "lovable". He likes to talk about building a minimum lovable product, then a lovable product, then an absolutely lovable one, and he carried that jargon into the company name. Lenny jokes that ALP is the new MVP.

Osika was CTO of a YC startup when ChatGPT arrived. Colleagues thought he was exaggerating how much it would change things, so he built an open-source tool, GPT Engineer, that turns an instruction like "create a snake game" into working code. It became the most popular open-source showcase of that ability, with around 50,000 GitHub stars.

He argues that cognitive labor is now being done better than humans by machines, and that the most positive impact is not making engineers more productive, as Copilot does. It is helping people who have struggled to find software talent turn their ideas into reality. He asked a former colleague and fellow founder, Fabian, to build a GPT Engineer for people who don't write code.

After iterating under a waitlist, the team launched Lovable on 21 November, and Osika says it hit 1 million ARR in a week and kept growing even faster. He also recounts that GitHub once shut Lovable off after it started creating around 15,000 projects per day, which tripped an on-call engineer's alarms.

Asked about the technical edge, Osika says there are many scaling laws in AI systems and the one that matters for Lovable is that putting in more work reliably makes the product better. AI builders are great at the start and then get stuck. His team painstakingly identified where, tuned the whole system quantitatively and built a very fast feedback loop to improve those areas.

Getting stuck usually means the AI introduces a bug and can't get itself out of it. Lenny recalls that Replit's Amjad named unsticking the AI as a key human skill. Osika agrees it matters today but says the frontier of the problem is receding quickly.

The team focused first on the most important cases: adding login, creating data persistence and adding payments with Stripe. Osika expects that, over time, people will not need to be good at unsticking the AI because the experience will simply not get stuck.

Osika is modest about the 15-person, 10-million-ARR story. He says Lovable builds on foundation models, which he likens to discovering oil, and the team's contribution is obsessing over the right interface for humans and packaging pieces like authentication so they work together. People love the product, he says, and that drives growth, with awareness coming mainly from posting what they ship on social media.

He credits the team above all, saying he has hardly written code recently. He wants people who ship very fast and have taste for simple abstractions. Lovable is set up so it can change itself, though it doesn't do everything: the team spins up a dedicated computer per user and mostly uses developer tools such as Cursor for the rest.

On competitors such as Bolt and Replit, Osika says Lovable's focus is packaging for non-technical people, with instant visual edits. It also syncs with GitHub, so engineers can work in Cursor on the same project while others stay in Lovable. His main claim is reliability: not getting stuck, which he says people he speaks with rank as the most dependable.

Looking ahead, Osika sees going from desired change to fully working, integrated product becoming almost instant. He also expects AI to analyze user behavior at massive scale, propose changes and run A/B tests automatically.

Lenny proposes that the valuable skills are shifting toward figuring out what to build and judging whether it is good and ready, now that building is increasingly handled by AI. Osika agrees: finding pain points and making something ten times better matters, and taste matters even more.

Engineering skill still helps because it reveals constraints. Osika says engineers worried about their jobs should see themselves as translators from human problems to technical solutions, and abstract themselves up a few steps instead of staying within one tech stack.

For his own product team, he would hire for as many skill sets per person as possible. Everyone should know how to architect a system, have product taste and talk to users. Being a generalist, he says, is much more important than it used to be.

Lovable has 18 people, up from 15, and about 12 of them write code at least part-time. Osika says the most important trait is caring a lot about the product, the users and how the team works together, ideally to the point of obsession. On top of that, he wants a generalist brain that learns quickly plus one dimension of real superpower, which for Lovable means getting the most out of large language models.

In interviews he asks what candidates did before and listens for deep care and technical detail. The team then presents a hard, unorthodox problem to see how they think, and nearly always has candidates join a work simulation for at least a day, often a full week.

The team's job ad is inspired by Shackleton's famous recruitment notice, warning of long hours, high urgency with AGI timelines approaching, and a difficult mission, and promising a generous share of the venture's success. Osika says he got help with formatting but wrote the phrasing himself, and Lenny notes that a filter this clear draws exactly the people who want it.

On building in Sweden, Osika says the ambition in that job ad is rarer there than in the US, but raw talent is more available. He sees inspiring people to be more ambitious as a real advantage, if a double-edged one, and says finding the people who would want such a mission is a big part of the work.

Osika's prioritization algorithm is simple: identify the biggest problem, solve it fast, then pick the next one without dreaming up a long roadmap. The biggest problem isn't always obvious, so the team talks to users and reads a public feature board. Because solutions can be tangled in technical details, he says the company is more engineering-led than most product companies.

The cadence is weekly planning around a big FigJam board of problems, followed by a demo of what shipped. There is now a roadmap covering custom domains, collaboration and, as the largest initiative, making the system more agentic. The roadmap is clear for a month and stretches to three, and the team tracks work in Linear.

Asked when an engineer will be an AI agent, Osika says the label matters less to him, since AI is always redefined as whatever computers can't yet do. For speed, he credits working from the office and especially eating lunch together, which cross-pollinates ideas and gives high-bandwidth communication.

For product teams in general, he says everyone should be excited about using AI and able to work well together. The bottleneck is shifting from engineering to taste and intuition about users. The strongest correlate of being at Lovable, he says, is raw cognitive ability, together with a startup mindset that prefers speed and iteration over structure.

Osika expects a "Cambrian explosion" of entrepreneurship as people who failed for lack of technical help can now build their own ideas. Instead of long meetings or documents, people will build and show their idea.

Next for Lovable is more agentic behavior, meaning the system gets more freedom to decide what to do next, such as writing tests and fixing failures. It will also add custom domains and collaboration, and the team is thinking about helping founders get users, feedback and word out after building. Lenny notes that go-to-market is a different skill, and Osika says Lovable already shares playbooks on its blog.

He clarifies that Lovable cannot yet work on arbitrary existing code bases. A research preview of importing exists, and projects started in Lovable can be edited by engineers in any tool. Supporting existing apps is something he says is coming.

For his failure story, Osika recalls being the first employee at Summer Labs, which built an API to personalize learning with AI. It was hard to retrofit into other companies' products, and the company wasn't very successful at it. The lesson: start with how the product works end to end, then add AI to solve specific problems. Lenny jokes that Lovable should add a "Lenny mode" that asks founders why they're building something.

Osika's closing advice is to have fun with the change and become a top 1% user of AI tools, which he says is the best move for your current job or a new one. To get there, pick an outcome you want and spend a full week using AI to reach it. He says surrounding yourself with others who share the obsession would quickly put you in the top 0.1%.

Lenny summarizes it as finding a pain point and solving it end to end, from idea to something someone actually uses. Osika adds that you should ask the AI whenever you don't understand. For Lovable use, he recommends chat mode, which is activated through a flag in the user profile and is not yet in the main product, and says to ask other tools or general chatbots about other domains.

People can follow the company's updates on X at lovable_dev and Osika at AntonOsika, join the Discord, and request features at feedback.lovable.dev. He says feedback on where people see big changes in their work is the most useful thing listeners can offer.