# Lovable: building full apps from natural language > Lovable generates full-stack web apps from a description, with editable code. Plans and prices as of October 2026, credits, security and when it makes sense. *Tags: ai, tools, vibe-coding, prototyping* --- > [!info] Quick Definition > **Lovable** is an AI development platform for creating, iterating on and publishing web applications from natural language. Unlike a screen generator, the app includes frontend, backend and database, and the code stays editable and synced with your repository. ## What does Lovable do? According to its official documentation, you describe the app and Lovable generates the frontend, backend, database, authentication and integrations, all backed by editable code. The editor has two halves: the project chat on the left, where you describe changes one at a time, and the live preview on the right, with a toggle for the mobile view. Every change is saved as a version you can restore. You can also select an element in the preview and describe the change, or edit text inline without writing a prompt. To publish, you click **Publish**; Lovable suggests a `lovable.app` address you can edit. According to the documentation, publishing is free on every plan, and the live site is a snapshot: later changes only go out when you publish again. The project syncs with GitHub, GitLab or Bitbucket so it fits existing engineering workflows. The platform also has desktop and mobile apps, integrations with Slack, Telegram and ChatGPT, and an MCP server to drive Lovable from your own AI tools (see [[mcp|MCP]]). ## Why does it matter to a designer? Because it lets you go from an idea to an app someone can use in a day. That is useful for validating a flow with real users, but it also sets a trap: an app that works in a demo may lack error states, permissions and properly protected data. For a designer, the right question is not "can I build this?" but "which part of this app must be final and which can stay a prototype?" If you treat it as a prototype, Lovable is a good lab. If you treat it as a product, it needs the same reviews as any development. To place it among other tools, see [[vibe-coding-tools-comparison|the vibe coding tools comparison]], [[bolt|Bolt]] or [[v0|v0]]. ## How much does it cost and how do credits work? Lovable charges by credits, not by projects or seats, and every plan allows unlimited workspace members. According to the official documentation, checked on October 27, 2026: | Plan | Starting price | What it includes | |---|---|---| | Free | Free | 5 daily build credits (up to 30 per month), 20 Cloud and 4 AI credits per month, publishing to up to 10 invited people per project, community support | | Pro | 25 USD/month for 100 monthly credits (21 USD/month billed annually) | Everything in Free, plus monthly credits, credit rollover, top-ups, usage limits and alerts, custom domains, code editing and download, and email support | | Business | 50 USD/month for 100 monthly credits (42 USD/month annually) | Everything in Pro, plus SSO, role-based access, security center, the Lovable API, passwords on preview links and priority support | | Enterprise | Quoted through sales | Volume-based credits, SCIM, audit logs, data exports, scheduled security scans and EU inference | Monthly credits on Pro and Business scale in tiers: for example, 200 credits cost 50 USD on Pro and 100 USD on Business, so a Business credit is more expensive. Unused monthly credits roll over while the subscription stays active and expire two months after issue on monthly plans. Daily credits and the monthly Cloud, AI and connector grants do not roll over. Verified students and teachers get 50% off Pro with 100 credits, for up to 12 months. Since every change consumes credits, measure how many a typical screen uses in your tests before choosing a plan. ## How secure is a generated app? Lovable includes two scans. The **Quick scan** checks database access rules, npm dependencies and MCP server exposure, and runs when you publish. The **Deep scan** reviews all code for access control problems, injection, leaked secrets and payments, but you have to start it manually. The documentation warns that misconfigured row-level security (RLS) rules are a common cause of data leaks, and that you are responsible for making sure the app meets the security requirements of its use case. The tools "cannot guarantee complete security". More in [[vibe-coding-security-basics|vibe coding security basics]]. ## When should you NOT use Lovable? - When the app handles personal or financial data without an additional security review. - When your team already has a mature product and repository: mixing a full generator with existing code creates architecture conflicts. - When your budget cannot support iteration, because credits are spent with every change. - When you need direct support: on Free there is only community support. ## Example Illustrative example: a designer wants to validate a booking app for a yoga studio. She writes: "Create an app with login, a class calendar, class bookings and an admin panel for the instructor." Lovable generates the base. She tests the flow with five people, notes that the booking confirmation does not show remaining spots and asks for that change. Before showing it to real clients, she checks what the users table stores, runs the security scan and configures permissions, because that part was not in her Figma file. What she learned: the app helped her validate the flow, and security was a step she had to request and review. ## Steps to start without getting lost 1. **Write a prompt for one page**, not a full app. Define the goal and the first flow. 2. **Ask for the states**: empty, error, loading and no permission. 3. **Review the database** and the access rules before adding more features. See [[databases-for-designers|databases for designers]]. 4. **Sync with GitHub** once the prototype becomes important. 5. **Test with real users** before publishing large changes. ## Common mistakes - Treating a working demo as a finished product. - Asking for many features in one prompt, which makes errors harder to find. - Not reviewing permissions and what the database stores. - Spending credits iterating on small changes you could make by hand or with inline text editing. - Publishing without reviewing copy, accessibility or privacy policies. ## Sources - [Lovable: introduction documentation](https://docs.lovable.dev/introduction) - [Lovable: getting started](https://docs.lovable.dev/introduction/getting-started) - [Lovable: subscription plans](https://docs.lovable.dev/introduction/subscription-plans) - [Lovable: plans and credits](https://docs.lovable.dev/introduction/plans-and-credits) - [Lovable: security](https://docs.lovable.dev/features/security) - [Lovable: pricing page](https://lovable.dev/pricing) --- Source: https://www.fernandoux.com/en/wiki/ai/lovable/