Lovable

Lovable is the tool that finally makes the “I’ll just build it myself” instinct viable for non-technical founders. Not viable in a “you could hack something together” way — viable in a “you could charge customers for this” way. That’s a genuine shift, and it’s worth being specific about why.

New in April 2026: Lovable on iOS and Android

On April 28, Lovable launched native mobile apps on the App Store and Google Play. The app is free to download, syncs projects across phone and desktop, and lets you build by typing or by speaking — voice prompts are first-class on mobile, which is genuinely useful when you’re standing in line at the airport and an idea hits. You can preview the result in the in-app browser, hand off to the agent to keep working in the background, and pick up on your laptop later without losing context.

The realistic boundaries are worth flagging up front. Apple won’t let the iOS app host generated apps directly, so production publishing still happens from the web — the mobile app previews and iterates, but you’ll go to lovable.dev to deploy. The mobile editor is also intentionally narrower than the desktop one: you can prompt, preview, edit copy, and approve agent-suggested changes, but most fine-grained controls (Design View tweaks, MCP server config, deeper code edits via the GitHub integration) are still desktop-first. Treat the mobile app as the capture and approval surface, not a full replacement for the web editor.

What changes for non-technical founders: the friction between “I had an idea” and “the agent is now building it” drops to nearly zero. Voice prompting on mobile is the right modality for early ideation — describe the app for a minute, let the agent draft a starting point in the background, then review and refine on a real screen later. Whether that meaningfully changes outcomes depends on your workflow. Founders who already work in tight, focused desktop sessions probably won’t change much. Founders whose best ideas show up while walking, driving, or waiting in line just got a real tool for that.

New in April 2026: Lovable 2.0 and a built-in security scan

On April 24, Lovable published its official response to the April 2026 incident and shipped Lovable 2.0, headlined by a new in-product security scan that checks your project for common misconfigurations before you invite real users. The scan covers whether Row-Level Security is enabled on Supabase tables, whether public endpoints are exposing data that shouldn’t be public, and whether API keys and secrets are stored correctly. Every project gets it for free and it runs automatically on publish.

The honest caveat: early third-party reporting suggests the scanner flags the presence of RLS without verifying the policies actually do what they should. That gap matters — a table can have RLS “enabled” and still leak data if the policy is written wrong. Treat the green checkmark as a sanity check, not a security sign-off, and combine it with the Aikido pentest integration before you onboard paying customers or store regulated data. For most validation-stage builds, the new scan is a genuine improvement over “you’re on your own.” For anything past validation, the same rule as two weeks ago still applies: pay for an independent security review before go-live.

New in April 2026: A serious security disclosure you should read before building

On April 20, a security researcher published a credible claim that a Broken Object Level Authorization (BOLA) flaw in Lovable’s API let any free account read other users’ source code, database credentials, AI chat histories, and data — specifically on “public” projects created before Lovable’s February permissions rework. The researcher reported it via HackerOne on March 3, where it was closed as a duplicate without Lovable patching the underlying issue on pre-existing projects. Lovable initially denied there was a breach, pointed at HackerOne, and attributed the exposure to “intentional behavior” plus unclear documentation. On April 21, the company issued a second statement that was closer to an apology but still laid significant blame on HackerOne, while confirming it has reverted the change that re-opened access to public-project chats. See our full write-up in Lovable’s April 2026 data exposure — what founders need to do now for the detailed timeline and the checklist.

What this means if you’re using Lovable today. The immediate hole for public projects has been closed. Private projects were not affected by this specific flaw. The harder question is trust: this is Lovable’s second major security story in under two months (see our Lovable security crisis guide for the February RLS story), and the initial response here was defensive before it was corrective. That doesn’t make Lovable unusable — it means the same rule as before applies, only louder: don’t store real customer PII, payment credentials, or sensitive business data in a Lovable-built app without an independent security review. For validation-stage MVPs with fake data, Lovable is still the fastest path. For anything past validation, bake a security pass into your launch checklist.

New in April 2026: Chat Mode, follow-up questions, and Lovable Payments

Two launches in the past week are worth flagging for day-to-day users. First, Chat Mode (April 17) lets you start a new project by conversing with the agent about your idea before a single line of code is generated. Lovable will ask follow-up questions — scope, auth model, core entities, layout preferences — and only build once you’ve confirmed a direction. The net effect is fewer “that’s not what I meant” iteration loops and lower credit burn on early prompts. Turn it on from the new-project picker; it’s opt-in.

Second, Lovable Payments (April 13) lets apps built in Lovable accept payments from 200+ countries with VAT and sales tax handled for you. Paddle is the default merchant of record; Stripe and Shopify are supported as integrations. You can configure one-time payments or subscriptions in a few prompts and run a sandbox-mode test flow before going live. For founders who used to hit a wall the moment they needed a real checkout, this is the cleanest path to collecting revenue inside a Lovable-built app.

New in April 2026: Claude Opus 4.7 support and a visible response to Anthropic

On April 16, Lovable rolled out Claude Opus 4.7 as the default model across the platform. In Lovable’s own benchmarks, tasks complete in roughly 40% fewer turns — which translates directly into fewer credits consumed per build. To sweeten the transition, every paid user got double credits through the end of April. That discount wasn’t incidental: it landed the same week leaks revealed Anthropic is building an in-chat app builder of its own, and the same week Anthropic officially launched Claude Design. Lovable staff reportedly worked overnight to ship the upgrade.

The competitive context matters if you’re evaluating the tool today. Lovable’s moat was “fastest path from idea to working SaaS for non-coders.” Anthropic is now actively trying to collapse that into Claude itself. For now, Lovable’s output quality, Supabase-backed architecture, and team-focused features (MCP servers, Design View, SSO) still make it the more mature choice. But the gap is shrinking, and that should factor into how you think about tool lock-in.

New in April 2026: MCP servers, Design View, and $400M ARR

Three things happened in the past few weeks that are worth knowing about.

First, Lovable launched MCP server support — which sounds technical but has real practical value. MCP (Model Context Protocol) lets Lovable read from your existing work tools: Jira tickets, Confluence docs, Notion pages, Linear issues, and n8n workflows. Instead of copy-pasting a PRD into chat, you connect your Notion workspace once and Lovable reads the context directly. For teams that live in project management tools, this cuts the overhead of translating specs into prompts significantly. Business and Enterprise plans can also add custom MCPs. This is the first sign that Lovable is moving beyond “solo founder builds an MVP” and toward “small team ships a real product.”

Second, a new Design View brings visual editing into one place — themes, image generation, and layout controls that previously required prompting. Themes let you define brand standards (colors, typography, spacing) once and reuse them across your workspace. You can create multiple themes and switch between them without re-prompting. It’s a meaningful step toward Lovable feeling like a proper design tool rather than a chat window with a side preview.

Third, Lovable added built-in penetration testing in partnership with Aikido Security. You can now run an automated security audit against your Lovable-built app — a swarm of AI agents attempts to exploit OWASP Top 10 vulnerabilities, privilege escalation issues, and data exposure gaps, then generates a formal report suitable for investor due diligence or SOC 2 purposes. It costs $100 per test and takes one to four hours. For founders shipping to real users, this is meaningful: the common criticism of vibe-coded apps (that they’re insecure by default) now has a practical counter. Enable Aikido in your project settings under Connectors to access it.

Second, Lovable announced it has reached $400 million in ARR — up from $200 million at the end of 2025, quadrupling in roughly four months. CEO Anton Osika also announced the company is actively seeking acquisitions, looking for “builder-first, high-agency teams” to bring in-house. The $6.6 billion valuation and the M&A posture signal that Lovable is playing the long game: not just a builder tool but an attempt to own the full stack of how non-technical founders build software.

None of this changes the day-to-day experience of using Lovable. But it does mean you’re building on a platform with significant resources behind it, which matters when you’re deciding whether to commit a real product to it.

What Lovable actually builds

When you describe an app to Lovable, you don’t get a static mockup or a frontend shell. You get a React application wired to a Supabase backend — with real authentication, a Postgres database, row-level security, and API routes. The gap between “it looks like an app” and “it is an app” is where most no-code tools fail silently. Lovable closes it.

For an MVP, that matters enormously. You can share a Lovable-built app with real users, gate it behind auth, persist data, and iterate based on what you learn. Most tools in this category produce demos. Lovable produces software.

The editing experience

The workflow is chat-driven: you describe what you want, Lovable generates the change, and a live preview updates in seconds. There’s version history with undo. There’s a GitHub integration so developers can pick up where you left off. There’s even a “select element” mode where you can click on something in the preview and describe changes to it directly.

The iteration speed is legitimately remarkable. Experienced Lovable users report going from blank canvas to something shippable in four to six hours. That’s not a marketing number — it’s consistent with what the tool actually delivers on straightforward SaaS projects.

New in April 2026: Pricing changes

Lovable updated its pricing structure this month. The old $20/month Starter and $50/month Pro plans are gone. The current tiers are: Pro at $25/month (100 monthly credits, standard features), Business at $50/month (100 credits plus SSO, priority support, and additional seat options), and Enterprise at custom pricing for larger teams. If you were on the old Starter plan and were happy at $20, you’ll want to evaluate whether the new $25 Pro still makes sense — the credit count is the same, but the price bump is real.

Pricing: what you actually need to budget

The free tier gives you 5 messages per day. That’s enough to explore the tool, not enough to build anything real. For serious MVP work, the $25/month Pro plan is the entry point. It gets you 100 credits per month, which sounds like a lot until you’re mid-iteration on a tricky feature.

Heavy users — founders actively building and iterating — will find the Business plan at $50/month adds SSO and priority support but not unlimited credits. If you’re treating Lovable as your primary development environment, budget at least $25/month and potentially $50 if your team needs shared workspace access. The math still beats hiring a freelancer for a weekend.

Where it falls short

Lovable’s biggest weakness is its ceiling. Once you need something genuinely custom — a multi-step webhook flow, a custom payment integration that goes beyond Stripe basics, real-time features with WebSockets — the AI starts struggling. It doesn’t fail loudly; it generates plausible-looking code that subtly doesn’t work. That’s more dangerous than an obvious error.

The debugging experience also trails behind the authoring experience. When something breaks, you’re reliant on pasting errors into chat and hoping the AI reads the problem correctly. Sometimes it does. Sometimes it goes in circles. If you’re not a developer, knowing when to stop prompting and call in a human is a skill you’ll need to develop.

What “I don’t code” really means here

You don’t need to write code to use Lovable effectively. But you do need to understand the architecture it creates, because when you hand this off to a developer (which you eventually will), they’ll need to understand it too. Supabase for the database, React for the frontend, Vercel for hosting — that’s the stack. An hour of reading on each will make you a far more effective Lovable user.

What people have built with it

• Plinq — A women’s safety SaaS built by a first-time non-technical founder; reached 10,000 users and $456K ARR.
• DummyForms — A no-code form builder with AI generation; placed third in Lovable’s 2024 hackathon and launched on Product Hunt.
• Kolbo.AI — A unified AI content platform (60+ models) built by a 3D artist with zero coding experience.

Browse the full gallery at Made with Lovable.

Verdict

Lovable is still the best tool available right now for validating a SaaS idea without engineering resources. If the alternative is waiting to hire a developer or learning to code, Lovable is the clear choice. The output is real, the iteration speed is competitive, and the cost is rounding-error territory compared to what a developer would charge.

The ceiling is real, but most founders never hit it during validation. Start there. If you build something people want, figure out the scaling problems then — and after the April 2026 BOLA disclosure, treat “the scaling problems” as including a proper security review. Don’t put real customer PII, payment credentials, or regulated data into a Lovable-built app you haven’t paid someone to pressure-test. That’s the honest bottom line right now.

Was this helpful?

YesCould be better