DEV Community: Aakash Verma

Google Play Developer Account Cost: $25 and 14 Days

Aakash Verma — Fri, 13 Nov 2026 23:46:55 +0000

A Google Play developer account costs US$25, one time, paid by credit or debit card when you sign up for Play Console (Google's sign-up guide, checked November 2, 2026). No yearly renewal, unlike Apple's $99. Prepaid cards aren't accepted, and if your ID and card details don't check out, Google keeps the $25.

That's the whole fee. The cost founders don't see coming is time. If you open a personal account, Google won't let your app into production until it has run a closed test with at least 12 testers, opted in continuously for 14 days (App testing requirements). Then you apply for production access, and Google says that review "usually takes seven days or less." So on a personal account, the realistic path from "I paid the $25" to "my Lovable app is on Google Play" is three weeks, sometimes more.

Personal or organization: decide before you pay

This is the decision that matters, and you make it in step 4 of sign-up, right after paying.

Personal account. Your own name and ID. You get the closed-test rule above (it applies to personal accounts created after November 13, 2023), and you also have to verify that you have access to a real Android device through the Play Console mobile app before you can publish. Your name shows as the developer on the store listing.

Organization account. For a registered company. No 12-tester rule. Google asks for the company's details and a D-U-N-S number, and from the new Android developer verification work, a company website verified in Google Search Console. A D-U-N-S number is free from Dun & Bradstreet, but getting one can take from a day to a couple of weeks depending on the country.

If you have a company, open an organization account. The D-U-N-S wait usually overlaps with building the app, and you skip the testing rule completely. If you don't have a company and won't make one for this app, go personal and start recruiting testers early.

We had a founder last month who'd opened a personal account "to save time," then spent two weeks chasing friends to keep the test app installed. Three of them uninstalled it after a few days because they thought they were done. Google counts testers who stayed opted in, not testers who ever joined, so the 14 days restarted in practice. If you do the test, tell testers plainly: leave it installed for two weeks and open it now and then.

The 12 testers, without the panic

Testers join through an opt-in link from the closed testing track, with the Google account they use on their phone. They don't need to be developers. Google wants feedback too: when you apply for production you answer questions about the test and summarize the feedback, so give testers one thing to try each few days and keep notes from the Testing feedback page in Play Console.

Don't buy testers. There are services selling "12 testers for 14 days." Google asks how you recruited them and what you learned, and a test where nobody opened the app after day one is exactly what that question is there to catch. Your Lovable app's existing web users are the best testers you'll ever get, because they already care about it.

What else costs money on Google Play

Not much, up front. Uploading builds, internal testing and the store listing are free. The money starts when you sell. Since June 30, 2026, for users in the US, UK and EEA, Google Play's fee is split into a service fee plus a 5% billing fee: on your first $1M of earnings a year, that's 10% + 5% (Google's service fee table). Selling only to existing web users through Stripe on your website is a separate question, and we covered the Apple side in in-app purchases for a Lovable app.

One more date for anyone distributing outside the Play Store: Android developer verification started on September 30, 2026 in Brazil, Indonesia, Singapore and Thailand, and Google says it goes global in 2027 (Android developer verification). A Play Console account already covers this for apps you ship through Google Play.

The numbers for a Lovable app on both stores

	Google Play	Apple App Store
Account fee	$25, once	$99 a year (details)
Before your first public release	Personal: 14-day closed test, 12 testers, then review of up to about 7 days	Review of your build, usually a day or two (our notes)
Organization needs	D-U-N-S number, verified website	D-U-N-S number

The account is the cheap part. Getting the Android build right (an app bundle signed for Play App Signing, the target API level Google requires, a store listing that matches the app) is where most first submissions stall. Our walkthrough of getting a Lovable app on Google Play covers the build, and if you'd rather not do any of it, we publish your Lovable app to Google Play and the App Store from $300, including the closed test setup.

Originally published on lovable2app.com. Aakash Verma, software developer and founder of Lovable 2 Live.

Deploy a Lovable App to Vercel: What Moves

Aakash Verma — Thu, 12 Nov 2026 23:51:05 +0000

To deploy a Lovable app to Vercel today, you connect the project to GitHub in Lovable, import that repository at vercel.com/new, and click deploy. That's the whole official process, and for a current Lovable project it works, because Lovable apps are TanStack Start under the hood and Vercel added zero-config detection for them. What the two-step guide doesn't tell you is which half of your app actually moved.

We checked this on November 11, 2026 against Vercel's Lovable guide, its TanStack Start docs, and the source of @lovable.dev/vite-tanstack-config 2.27.0, the package that holds a Lovable project's whole build setup.

Check one version first

Open package.json and find @lovable.dev/vite-tanstack-config. Vercel says zero-config detection needs ^2.6.2 or newer. Anything recent is fine; the current release is 2.27.0, from late October.

If your project is older than mid-2026 you may not have that package at all. Older Lovable apps were plain Vite single-page apps with no server, and those deploy to Vercel as a static site, which is simpler and also a different post.

Here's why it works without config, straight from the package's own type definitions. A Lovable build runs Nitro, and Nitro's default target is cloudflare-module, because that's where Lovable hosts your app. But Nitro's own platform detection wins over that default. On Vercel's build machines, Nitro sees it's on Vercel and builds for Vercel Functions instead. Lovable's own builds set LOVABLE_NITRO_PRESET, so the two never fight.

If you build in your own CI and want to pin the target, the package takes nitro: { preset: "vercel" } in vite.config.ts. The same file warns you not to add the TanStack, React or Tailwind plugins yourself, and that warning is serious: you get duplicate plugins and a broken build. One more trap from the source: the old cloudflare option was removed in v2, so a config copied from an early-2026 tutorial gets a warning and the setting is ignored.

What actually moves

Your frontend and the server rendering. That's it.

If the app runs on Lovable Cloud, the database, sign-in, storage buckets, edge functions and their secrets all stay on Lovable Cloud. The app on Vercel talks to the same backend it talked to before. That's convenient (nothing to migrate, same users, same data) and it's also why this is not "leaving Lovable". You still pay Lovable Cloud usage, and if your balance hits zero the backend can pause, wherever the frontend is hosted.

The connection details come from the repo's .env file, VITE_SUPABASE_URL and the publishable key. Vite bakes VITE_ variables into the build, so they have to be there at build time. Lovable commits that file with the project, so the first Vercel build usually just works. If someone deleted it or added it to .gitignore (a developer tidying up the repo will do exactly that, it looks like a secrets file), add the same variables in Vercel's project settings and redeploy. The publishable key is meant to be public; your row level security is what protects the data, not the key.

Things that change on the day you switch

Sign-in links. Password reset and magic link emails point back to a URL your auth settings allow. If that list only knows the .lovable.app address, users on the new domain get bounced to the old one, or to an error page. Test a password reset on the Vercel URL before you move the domain, not after.

The domain. If your custom domain is connected in Lovable, its DNS points at Lovable. Move it to Vercel only when the Vercel deployment has been tested, and expect a short window where some visitors still hit the old host.

Previews. Every push to GitHub now builds on Vercel, including every commit Lovable makes while you prompt. That's 30 deployments on a busy afternoon. Free, but noisy, and each one is a public preview URL unless you turn on Vercel's deployment protection.

The plan. Vercel's Hobby plan is for personal, non-commercial projects. A product with paying users belongs on Pro, which is $20 a month per seat.

Is it worth it?

Honestly, often not. If the only goal is "my app on my domain", Lovable already does that. Moving the frontend to Vercel makes sense when you want Vercel's preview deployments for a team, your company already runs everything on Vercel, or you need edge config or logs Lovable doesn't expose.

If the real goal is to stop depending on Lovable for hosting and billing, the frontend is the easy half. The backend is the part that matters, and it doesn't move by importing a repo. That's a Cloud to Supabase migration (from $150, usually 1 to 2 days, everything moves, priced by table count), after which the app runs on a Supabase project you own and can sit on Vercel, Cloudflare or your own server. Not sure what either setup would cost you each month? The free Lovable cost check reads the repo and tells you.

Originally published on lovable2live.com. Aakash Verma, software developer and founder of Lovable 2 Live.

Capacitor Android for Lovable: First Build

Aakash Verma — Wed, 11 Nov 2026 23:48:45 +0000

To run a Lovable app as a Capacitor Android app you need Node 22 or later, Android Studio 2025.2.1 or later, and your project's code from GitHub. Then it's npm install @capacitor/android, npx cap add android and npx cap open android. Unlike iOS, you don't need a Mac: Windows and Linux are fine.

That's the part the Capacitor Android docs cover, checked November 5, 2026, with Capacitor 8 current and 9 listed as "next". What follows is the part they don't, the stuff that actually eats the first afternoon. If you already did the iOS side, read our Capacitor iOS first build for the setup both platforms share; I won't repeat it all here.

The versions, in one place

From the environment setup page: Android Studio 2025.2.1 (Otter) or newer, Node 22 or newer, and the Android SDK platform for API 24 or higher installed. Capacitor 8 apps run on Android 7 (API 24) and up, and target Android 16 (API 36). You don't install a JDK yourself. Android Studio ships the one Gradle needs, JDK 21.

The Android Studio version is the one people skip. Open a Capacitor 8 project in an older Studio and the Gradle sync fails with "The project is using an incompatible version (AGP 8.13.0) of the Android Gradle plugin". Nothing is wrong with your project. Update the IDE.

And when Studio offers to upgrade the Android Gradle plugin to 9, click no. We covered why in the Capacitor 8 upgrade post.

Adding the platform

npm install @capacitor/android
npx cap add android
npm run build
npx cap sync android
npx cap open android

cap add android creates an android/ folder with a real Gradle project. Commit it. Your icons, permissions in AndroidManifest.xml, signing config and version numbers all live there.

Before you run anything, check webDir in capacitor.config.ts. Lovable projects started since mid-2026 are TanStack Start apps whose normal build is a server bundle with no index.html, so cap sync either fails or copies the wrong thing. It's the same fix as on iOS (a client-only build in its own folder), and it's the first thing to sort out on either platform.

The four things that break first

"Plugin not implemented", but the plugin is installed. This one is very Lovable-specific. A lot of Lovable apps were asked at some point to "make it a PWA" or "work offline", so they ship a service worker, often through vite-plugin-pwa. Capacitor's troubleshooting guide says it plainly: service workers can stop Capacitor from injecting its code. Inside the app the service worker serves cached pages, the bridge never loads, and every native call fails. We spent most of an afternoon on a client's app where the camera button did nothing on Android and worked fine on iOS before anyone thought to look for a sw.js. Turn the service worker off in the native build. The website can keep it.

The header sits under the clock. Capacitor 8 targets Android 16, where apps draw edge to edge and the old config key that kept content below the status bar is gone. Your top bar slides under the system icons. The fix is CSS, env(safe-area-inset-top) padding on the header, which you'll want on iOS anyway.

Login works on the website, fails in the app. On Android the app's origin is https://localhost (on iOS it's capacitor://localhost). Supabase redirect URLs, OAuth callbacks and the CORS checks in your own edge functions were all written for your domain. Add the app's origin, and for Google or Apple sign-in add a deep link so the browser can hand the session back to the app. Email and password login usually works without any of this, which is why people think the app is fine until someone taps "Continue with Google".

It works on your phone but not the emulator, or the other way round. The Capacitor docs note that the system WebView doesn't update itself on emulators. An emulator on an old system image runs an old Chrome WebView, and modern CSS or JavaScript breaks there in ways you'll never see on a real phone. Use a recent system image and stop debugging Chrome versions from 2019.

Two smaller ones. "Unable to locate a Java Runtime" in the terminal means JAVA_HOME isn't set; point it at the JDK inside Android Studio, which the docs give for macOS as /Applications/Android Studio.app/Contents/jbr/Contents/Home. And "APK can't be installed" usually means an old build with the same package name is still on the device. Uninstall it.

Before the Play Store

Pick the application ID in capacitor.config.ts carefully, because Google Play ties the listing to it forever. Then the store side: Google Play wants an Android App Bundle (.aab), not an APK, and everything uploaded after August 31, 2026 has to target API 36, which Capacitor 8 already does. Our Android App Bundle post walks through signing and the version code. A new personal developer account also needs 12 testers for 14 days before it can publish, which is in our Google Play developer account post.

Most founders get the app running on their own phone in a day. Getting it accepted is a different week. If you'd rather hand over both, we publish Lovable apps to Google Play and the App Store from $300, with your app still built in Lovable afterwards.

Originally published on lovable2app.com. Aakash Verma, software developer and founder of Lovable 2 Live.

Lovable vs Figma Make: Who Keeps the Code?

Aakash Verma — Wed, 11 Nov 2026 00:07:58 +0000

Lovable vs Figma Make looks like a fight between two prompt-to-app builders, and on the first afternoon it is one. Both turn a sentence or a design into a working React app, both charge in AI credits, and both give you a public link. The difference shows up the week after, when someone has to keep building on what they made. Figma Make is a design tool that grew a code tab. Lovable is a code tool that happens to start from a chat box.

We checked both against Figma's pricing page and help center, and Lovable's plans, on November 9, 2026.

What you pay

Figma doesn't sell Make on its own. It comes with a Figma seat, and the seat decides your AI credits:

	Figma Make	Lovable
Free	Starter: 150 AI credits a day, up to 500 a month	5 credits a day, up to 30 a month
Entry paid	Professional Full seat, $16 a month, 3,000 AI credits	Pro, $25 a month, 100 credits plus 5 a day
Cheaper seats	Dev $12 or Collab $3, 500 AI credits each	None, one plan per workspace
Bigger plans	Organization Full seat $55, Enterprise $90 (both billed yearly)	Business, $50 a month
Publishing	Needs a Full seat on paid plans	Every paid plan

Don't compare 3,000 with 100. Figma's credits are spread across every AI feature in Figma, not only Make, and its help pages don't publish a fixed cost per Make prompt. Lovable's credits pay for building and, since June 2026, for running the live app on Lovable Cloud too. The honest summary is that a designer who already pays for a Full seat gets Make for nothing extra, and a founder who doesn't use Figma is buying a design seat to get an app builder.

Publishing: figma.site and a custom domain

Figma Make publishes to an address like three-random-words.figma.site. You can attach your own domain, but the number of custom domains depends on your plan and is shared with Figma Sites. There's password protection, which applies to the figma.site version and not the preview. One catch on the free Starter plan: Figma's help page says Starter users must also publish the file to the Figma Community, so your "private prototype" is a public community file too. Read that before you put a client's flows in it.

Lovable publishes to a lovable.app subdomain and takes a custom domain on paid plans. Neither gives you a server you control. Both host the thing for you, which is fine until it isn't.

The backend is where they split

Figma Make offers two backends. Payload, which Figma hosts in the eastern United States, comes with a database, file storage, auth and an admin panel. Or Supabase, where you connect your own Supabase project under Integrations. So far that sounds close to Lovable, which runs on Supabase too.

Then there's this line in Figma's own help page: "Figma Make currently uses key-value stores rather than setting up a full SQL database." In practice that means a single table of keys and JSON values, read and written by one generated server function. No orders table with a foreign key to customers. No row level security policy per table, because there's one table.

A founder sent us a Figma Make link a few weeks ago. Lovely booking flow, Supabase connected, published on a figma.site address, about 300 real bookings in it. Every booking was a JSON blob under a key like booking: plus a timestamp. Finding "all bookings for this customer next week" meant reading every row and filtering in JavaScript. It worked at 300. It would not have worked at 30,000, and adding a second staff login with different permissions was simply not possible without redesigning the data.

Lovable builds real Postgres tables on Lovable Cloud or your own Supabase project, with migrations and RLS policies it writes as it goes. They're not always good policies (we've written about what the Lovable security scan misses), but they are tables you can query, index and fix.

GitHub: one way vs both ways

This is the part I'd weigh most. Figma Make pushes to GitHub, and Figma's help page is blunt about it: "It's a one-way push from Figma Make → GitHub." Changes made in GitHub don't come back into Make, and the next push overwrites them. Make only pushes to repositories it created, only to the default branch, and only one GitHub account or organization can be connected per Figma team. Payload-backed apps don't get the GitHub integration at all yet.

So the day a developer fixes something in the repo, the Make file is a fork you can no longer use. You either stop prompting in Make or you lose the developer's work.

Lovable's GitHub sync goes both ways. A developer can push a fix, and the next Lovable prompt builds on top of it. That's the single reason we tell founders who plan to hire help later to start in Lovable rather than Make. It's not about which AI writes nicer components. Make's components are often nicer, honestly, because it starts from a real design file.

Which one to use

Use Figma Make when the output is a prototype: a clickable demo for investors, a usability test, a flow your designer wants to feel in the hand before anyone writes real code. If your team lives in Figma, it is the fastest way from a frame to something you can tap. You can even bring Figma designs into Lovable later when it's time to build the real thing.

Use Lovable when the app is the product, it holds data with relationships, and a developer will touch the code within a year. And if you've already built something real in Figma Make, plan the move early. Rebuilding the data as tables is a few days of work at 300 records and a much worse week at 30,000.

To see what a Lovable app will cost once it has users, run the free Lovable cost check on the repo. If the prototype works and you want it ready for real users, that's Lovable to production, from $500, and if it's on Lovable Cloud and you want the database in your own name, Cloud to Supabase starts at $150.

Originally published on lovable2live.com. Aakash Verma, software developer and founder of Lovable 2 Live.

Android App Bundle for Your Lovable App

Aakash Verma — Mon, 09 Nov 2026 23:50:20 +0000

To publish a Lovable app on Google Play you upload an Android App Bundle (an .aab file), not an APK: Google has required bundles for new apps since August 2021. With a Capacitor project you get one with npm run build, npx cap sync android, then either Android Studio's Build > Generate Signed App Bundle or npx cap build android --androidreleasetype AAB with your keystore details, and since August 31, 2026 that bundle has to target Android 16 (API level 36).

How do I publish my Lovable app on Google Play? The short answer, checked against Google's Play Console help on October 26, 2026:

Wrap the Lovable app with Capacitor so there's an Android project to build (or have us publish it for you).
Open a Play Console developer account ($25, one time).
Build a signed .aab targeting API level 36, as below, and upload it to a testing track.
If your account is a personal one created after November 13, 2023, run a closed test with at least 12 testers opted in for 14 days in a row before you can apply for production.
Fill in the store listing, the Data safety form and the content rating, then apply for production access. Google warns that some accounts' reviews take up to 7 days or longer.

Most first launches spend more time on step 4 than on everything else combined.

The command is the easy part. What trips people up is the keys, so most of this post is about those.

The build, in the order that works

Lovable edits your web code. The Android project in the android/ folder only gets those changes when you copy them in, so every release starts the same way:

npm run build
npx cap sync android

Skip the sync and you ship last week's app with a new version number. It happens more than you'd think, usually on the release where you were in a hurry.

Then build the bundle. The Capacitor CLI can do it in one line, per the cap build docs:

npx cap build android --androidreleasetype AAB \
  --keystorepath ../keys/upload.jks --keystorepass "$KS_PASS" \
  --keystorealias upload --keystorealiaspass "$KEY_PASS"

Android Studio's Generate Signed App Bundle wizard does the same thing with a form. If you live in the terminal, ./gradlew bundleRelease inside android/ works too once signing is set up in Gradle, and the file lands in android/app/build/outputs/bundle/release/app-release.aab.

Two things to check before you upload. versionCode in android/app/build.gradle has to go up on every upload, or Play Console stops you with "Version code 1 has already been used. Try another version code." And targetSdkVersion has to be 36 for anything submitted after August 31, 2026 (Google's target API page). Capacitor 7 projects target 35, so that means the Capacitor 8 upgrade first.

Two keys, and only one of them is yours

This is the part worth slowing down for.

When you sign the bundle on your machine, you sign it with your upload key. That key's only job is proving to Google that the upload came from you. Google then strips that signature and signs the APKs it builds for each phone with the app signing key, which Google generates and keeps for you under Play App Signing. New apps are enrolled automatically. Users never see your upload key at all.

That split is good news and bad news.

The good news: if you lose the upload key, you're not locked out. Make a new one, export its certificate with keytool -export -rfc to a .pem file, then in Play Console go to Protected with Play > Play Store protection > Manage Play app signing and click Request upload key reset (Play App Signing help). Before Play App Signing, a lost key meant a new app listing and starting over at zero reviews. Back up the .jks file and its passwords anyway. A password manager entry with both passwords and the alias saves a very annoying afternoon.

The bad news is the one that bites Lovable apps specifically.

Why Google sign-in works in testing and fails from Play

Your Lovable app probably has "Sign in with Google" through Supabase. In the native app that often means a Google Sign-In plugin, and Google only accepts sign-ins from an Android app whose certificate fingerprint (SHA-1) is registered in your Google Cloud OAuth client or Firebase project.

So you register the SHA-1 from your keystore, test a release build on your phone, everything works. You publish. Users install from Play and sign-in fails with ApiException: 10 (Google calls it DEVELOPER_ERROR). The app on their phone is signed with Google's app signing key, not yours, and that fingerprint was never registered.

The fix takes two minutes once you know it. In Play Console, open Protected with Play > Play Store distribution > Go to Play app signing, copy the SHA-1 of the app signing key (not the upload key; new apps on Google's quantum-ready hybrid signing show three keys, and you need all three fingerprints), and add it next to the existing one in Firebase or as another Android OAuth client in Google Cloud. Keep the upload key's fingerprint there too, so your own sideloaded test builds keep working. Google's help page says it in one line: register the Google-held key's fingerprint with your API providers, "not just your local upload key". Same goes for Facebook login, Maps API key restrictions and anything else that pins your app's certificate.

Getting it in front of people

Upload the first bundle to the internal testing track. It has no requirements, Play says builds usually reach testers within seconds, and it's the fastest way to find out whether the release build behaves like the debug one. If your developer account is a personal one created after November 13, 2023, you then need a closed test with 12 testers opted in for 14 days in a row before production unlocks. Our Google Play guide covers that rule and the rejections we see most.

A last opinion: don't put keystore passwords in capacitor.config.ts or commit them to the repo Lovable syncs with. That repo is the one you give contractors access to. Environment variables in your build machine or CI, nowhere else.

If you'd rather hand over the whole Android release, keys, fingerprints, bundle and store listing, that's what we do, at a fixed price.

Originally published on lovable2app.com. Aakash Verma, software developer and founder of Lovable 2 Live.

How to Make a Lovable App Production Ready

Aakash Verma — Sun, 08 Nov 2026 23:51:04 +0000

To make a Lovable app production ready in October 2026, run the Deep security scan (the Quick scan that runs when you publish only checks database rules, dependencies and MCP exposure), then test your row level security with two real accounts, because no scanner knows which user should see which row. After that it's operations: a custom domain with sign-in emails from your own domain, knowing that Lovable's daily backups cover the database but not your storage files, and checking the hourly email limits before launch day.

What the launch docs leave out (checked November 8, 2026). Lovable's security page covers the scans, and Supabase's production checklist covers a backend you run yourself. Four things fall between them for a Lovable Cloud app:

No point-in-time recovery. Supabase tells you to turn on PITR once the database passes 4 GB. Lovable Cloud keeps one daily backup for about 14 days and has no PITR, so a bad UPDATE at 4 pm loses everything since the night's backup. If that's unacceptable, the database has to live in your own Supabase project.
Auth emails and rate limits. Supabase's own email sender allows 2 auth emails an hour across sign-up and reset, and even with custom SMTP the default is 30 new users an hour. Send sign-in mail from your own domain and check the limit before launch day, not during it.
Email scanners eat magic links. Company mail filters open links to check them, which uses up a single-use sign-up or reset link before your user clicks it. Supabase's fix is a template link to a page on your domain with a "Sign in" button that then follows the real link.
CAPTCHA on sign-up, sign-in and password reset, which Supabase lists and no Lovable scan checks for.

None of the built-in scans is an OWASP ASVS review either. Our Lovable security audit uses ASVS 5.0 as the checklist, for $350 with the report in 2 days.

That's the short version. The rest of this post is the order we'd do it in, and why each step is there.

What Lovable already checks, and what it doesn't

Lovable has two built-in scans now, and people mix them up. The Quick scan runs automatically every time you open the publish dialog. It looks at tables without row level security, policies that let everyone through, leaked-password protection being off, known vulnerabilities in your npm packages, and MCP servers exposed without auth. It takes seconds and shows one line in the dialog.

The Deep scan does not run on its own. You start it from the project's Security view. It reads the whole codebase for access control holes, endpoints anyone can call, injection, secrets in the repo, payment logic a customer can tamper with and auth that can be bypassed. Lovable's own security docs say these tools "do not replace a thorough security review", and they recommend scanning first, fixing, then a pentest (Aikido, as a connector) before a major release.

Run the Deep scan. Fix everything marked Critical. It's free and it catches the dumb stuff.

The part no scanner can do

A scanner can see that orders has RLS on. It can't know that a customer should see their own orders, a shop owner should see orders for their shop, and nobody should see anyone else's. That's your business rule, and it lives in your head, not in the code.

So test it the boring way. Make two accounts. Log in as A, create data. Log in as B and try to read A's data through the API, not just the UI. Open dev tools, copy a request, change the ID, send it again. The classic Lovable failures we look for:

A policy that checks the user is signed in (auth.uid() is not null) instead of checking they own the row. RLS is on, the Quick scan has nothing to say, and every signed-in user can read every order.
An is_admin flag on the profiles table that the row owner can update. One PATCH and you're an admin.
Admin checks done in React only. The page hides the button, the API doesn't care.
An edge function with verify_jwt off that sends email. Congratulations, you run an open mail relay.

If that list makes you nervous, that's what our security audit does: two real accounts against every policy, written up by severity.

Keys that shouldn't be in the browser

Anything the frontend can read, a visitor can read. Stripe secret keys, OpenAI keys and the Supabase service role key (or the newer sb_secret_ key) belong in edge function secrets, never in a VITE_ variable or a constant in a component. The Deep scan looks for secrets in your code, which is good. It won't catch the key you pasted into the chat three weeks ago that ended up in a config file you've since forgotten about, if it doesn't look like a key. Search the repo yourself for sk_live, sk-, service_role and sb_secret.

Backups: know what you actually have

This one surprises people. On Lovable Cloud you get a daily database backup, kept for roughly 14 days, and you restore from More, Cloud, Database, Backups (database docs). Restoring rolls back schema and data together, so anything created after that backup is gone, and the app may stop matching the database if you changed the schema since.

And backups cover the database only. Files in storage buckets are not in them. If your app stores invoices, avatars or uploads, and someone deletes them, the backup doesn't bring them back. For a lot of apps that's fine. For an app where the uploads are the product, it isn't, and you want your own copy somewhere.

This is also one of the reasons founders move the backend to a Supabase project they own, where point-in-time recovery is an option. That's our Cloud to Supabase migration, if you get there.

Email limits on launch day

Lovable's built-in email is decent now: branded auth templates, sending from a notify subdomain of your own domain, 50,000 transactional emails a month included on paid workspaces. But there's an hourly cap. On Pro it's 100 app emails and 500 authentication emails per hour (email docs). When you hit it, new emails are rejected until the hour resets.

Picture a launch post that does well. 700 people sign up in the first hour, the confirmation emails stop at 500, and 200 people are staring at "check your inbox" with nothing in it. Most of them don't come back. If you expect a spike, either be on a plan with a higher cap, or send auth email through your own SMTP provider.

Domain, redirects, the boring bits

Custom domains are on paid plans only. Connect it, then go through every place the old lovable.app URL is hard-coded: auth redirect URLs, OAuth app settings in Google, Stripe webhook endpoints, links in your email templates. A sign-in that redirects back to yourapp.lovable.app after you've moved to yourapp.com is the most common "it worked yesterday" bug we see after a domain switch.

Then add error reporting. Sentry's free tier is plenty for a new app and it takes about ten minutes. Without it, your users find the bugs and tell you on Twitter, or more likely, they don't tell you at all.

What production ready doesn't mean

It doesn't mean a rewrite. Most Lovable apps we look at are a few days of work away from being safe to put real users on, not weeks. Fix the policies, move the keys, sort out backups and email, connect the domain, add monitoring. If you'd rather hand that list to someone, Lovable to production is the fixed-price version, and the free cost check tells you what running it will cost once it's live.

Originally published on lovable2live.com. Aakash Verma, software developer and founder of Lovable 2 Live.

Capacitor iOS for a Lovable App: First Build

Aakash Verma — Sun, 08 Nov 2026 01:29:24 +0000

Getting a Lovable app running as a Capacitor iOS app takes four commands and one Mac. Getting it to build cleanly the first time takes a bit more, and almost none of the extra is in the docs. This is the version we'd hand a founder who wants to try it themselves before deciding whether to pay someone.

Facts below are from the Capacitor iOS docs, checked November 4, 2026. Capacitor 8 is current there, with 9 listed as "next".

What you need before anything else

A Mac. There's no way around it for iOS: you need Xcode 26.0 or later, which only runs on macOS. The app itself can support iPhones back to iOS 15. You'll also want a free Apple ID signed into Xcode for running on your own phone, and the paid Apple Developer Program ($99 a year) once you want TestFlight or the App Store.

Your Lovable project has to be on GitHub, because Capacitor works on the code in your repo, not inside the Lovable editor. Connect GitHub from Lovable, clone the repo, and run npm install locally.

The four commands

npm install @capacitor/core @capacitor/cli @capacitor/ios
npx cap init "My App" com.mycompany.myapp
npx cap add ios
npx cap open ios

cap init writes capacitor.config.ts. Think about the bundle ID before you type it (com.mycompany.myapp). It ends up in App Store Connect and you can't change it on a live app without shipping a new one. We've had a founder use com.lovable.test "just for now" and then publish with it. It's still there.

cap add ios creates an ios/App folder with a real Xcode project. Commit it. People treat it like a build artefact and gitignore it, then lose every icon, permission string and signing setting they configured.

The webDir problem in newer Lovable projects

Capacitor copies a folder of static files (your built web app) into the iOS project, and webDir in capacitor.config.ts says which folder. For years that was dist and it just worked with Lovable apps.

Lovable projects started since mid-2026 are server-rendered TanStack Start apps. Run npm run build on one and you get a server bundle, not a folder with an index.html Capacitor can load. npx cap sync will complain that it can't find index.html in your web assets directory, or worse, it copies something and the app opens to a white screen.

The fix is a client-only build of the app for Capacitor, its own output folder, and webDir pointed at it. It's a config change, not a rewrite, but it's the step that stops most people. Older Lovable projects built on plain Vite don't have this problem. If you're not sure which you have, we wrote up what the current Lovable template generates.

Some people skip all this and set server.url to the live website, so the app is just a window onto it. Don't ship that. It's the quickest route to a guideline 4.2 rejection, and the app is blank with no signal.

CocoaPods or Swift Package Manager

The docs still describe iOS projects managed with Xcode and CocoaPods, opened from ios/App/App.xcworkspace. Swift Package Manager is the other option, chosen when you add the platform with npx cap add ios --packagemanager SPM.

Our take: SPM for a new app, because it means no Ruby and no pod install, and that's where Apple tooling is heading. The Capacitor SPM guide warns that plugins without an SPM version won't work properly, and Cordova plugins "should work" but might not. So check your plugin list first. If you depend on an old Cordova plugin for something like barcode scanning, CocoaPods is still the safer choice.

The first errors, and what they mean

"Signing for App requires a development team." Open the App target in Xcode, go to Signing & Capabilities, pick your team. With a free Apple ID you can run on your own phone, but the app stops launching after 7 days.

A white screen on the simulator. Nine times out of ten, the web build is missing or stale. Run your build, then npx cap sync ios, then run again. Capacitor doesn't rebuild your web app for you.

API calls fail on the device but work in the browser. Your app now runs from capacitor://localhost, not your domain, so anything that checks the origin rejects it. Supabase auth redirect URLs and CORS rules on your own edge functions are the usual suspects. Add the Capacitor origin and a deep link for the OAuth return.

"pod install" errors. Usually an old CocoaPods or Ruby. Another reason we lean towards SPM.

After it runs

Running in the simulator is maybe a third of the job. Icons in every size, a splash screen, permission strings for the camera or location, push notifications, a reviewer login for App Review, and enough native behaviour that Apple sees an app rather than a website: that's the rest, and it's where first submissions usually stall.

If you'd rather skip to the end, we take Lovable apps to the App Store and Google Play as a fixed-price job, from $300, and keep the app building from the same code you edit in Lovable. The publishing service has the details.

Originally published on lovable2app.com. Aakash Verma, software developer and founder of Lovable 2 Live.

Lovable Database: Backups, Limits, Export

Aakash Verma — Sat, 07 Nov 2026 00:06:56 +0000

The Lovable database is a managed PostgreSQL database that comes with Lovable Cloud, one per project, on Supabase's open-source stack. You get a table browser, a SQL editor, daily backups kept for about 14 days, and an export capped at 15 GB. You don't get point-in-time recovery, you can't change the region after it's created, and you can only install the extensions on Lovable's list.

That's the short version. The rest of this post is what those limits mean once real users are writing to it, from Lovable's database docs and the backup and performance pages next to it, all checked on November 5, 2026. The docs carry no dates, so if you're reading this in 2027, check them again.

Where it lives in the editor

Open More → Database. You see your tables with an approximate row count, and you can double-click any value to edit it. Under Manage there are six tools: Jobs, SQL editor, Edge functions, Backups, Policies and Settings. Settings shows the Database location row, which is the only place you'll see the region and the Postgres version.

One line in the docs deserves to be in bold, so I'll do it for them: edits in the Database view go straight to the database your published app uses. There is no staging copy. A founder we worked with fixed a typo in a plans table on a Friday afternoon by double-clicking the price cell. It was the price_id column, not the display name, and Stripe checkout failed for every new customer until Monday. The view doesn't refresh live either, so he didn't even see his own change until he hit Refresh.

Small things worth knowing: pages show 10, 25, 50 or 100 rows, row editing only works on tables with a single primary key, views are read-only, and there's no import button. To load a CSV you attach it in the chat and ask Lovable to add the rows. CSV export does exist, and it exports every row matching your filter, not just the page you're looking at.

How the schema changes

You ask in chat, Lovable writes a migration. New projects keep those in drizzle/migrations/ (older ones in supabase/migrations/), and the docs ask you not to touch drizzle/schema.ts or drizzle.config.ts.

The interesting part is what Lovable refuses to do. By default the agent permission Execute backward incompatible database migrations is set to Never allow, so it won't drop or rename a column, change a column's type, or add a required column without a default. Instead it adds a new column, copies the data across, and leaves the old one where it was.

That's a sensible default for an app with users. It's also how a six-month-old Lovable project ends up with status, status_v2 and order_status on the same table, two of them dead, and code that still reads the wrong one in one place. Set the permission to Ask each time once you know what you're doing. You'll see the SQL before it runs, which is how it should have worked in the first place.

Extensions: a fixed list

Supported: pg_cron, pg_net, pg_trgm, vector, btree_gist, btree_gin, unaccent, fuzzystrmatch, postgis and pgmq. Preinstalled: plpgsql, pg_graphql, pg_stat_statements, pgcrypto, uuid-ossp and pgsodium. Anything else is refused, in chat, in the SQL editor and through the API, which answers with a 403 and unsupported_extension.

For most apps that list is plenty. vector covers embeddings, pg_cron covers scheduled jobs, postgis covers maps. If your plan depends on something that isn't there, find out now, not after launch.

Backups: daily, about 14 days, no rewind

Lovable takes one backup a day and keeps roughly 14 of them, listed under Manage → Backups with the time in UTC. Restoring is one button, Restore to this backup, and it can't be undone: everything written after that backup is gone, and the database is down for a few minutes while it restores.

There is no point-in-time recovery. If someone runs a bad UPDATE at 4 pm and the last backup was at 2 am, you lose 14 hours of orders to undo it. The SQL editor does ask for confirmation before UPDATE, DELETE, DROP, TRUNCATE and ALTER, which helps until the day someone clicks yes.

Backups cover the database only. Files in storage are not in them.

Export: what it takes, and what it leaves behind

From Manage → Settings, Export data produces a compressed Postgres archive you load with pg_restore. Lovable emails you when it's ready and you download it from More → Storage. The limits are the ones that matter if you're planning to leave one day: databases up to 15 GB, an export file up to 5 GB, one export every 24 hours, and the database must be running. A project paused because it ran out of credits has to be resumed first, which means buying credits to get your own data out.

The export includes your tables, your data and your users with their password hashes. Here's what it doesn't include, from the backups page:

Storage files, edge function code, secrets, sign-in provider settings and project API keys all move separately. The code comes over with GitHub sync. The files you download yourself. Secrets and Google or Apple sign-in you set up again at the destination. Users keep their passwords after a restore into Supabase, but everyone who was signed in has to sign in again.

Sizes and what they cost

The Free plan is fixed at Tiny. Paid plans can pick Tiny, Mini, Small, Medium, Large or X-Large under Settings → Database size → Manage; a resize takes a few minutes with a short restart. Some older projects show 2X-Large, which can't be selected again once you leave it. Storage starts at 8 GB, can grow up to 5 times per change and 4 times a day, and never shrinks.

Lovable doesn't publish prices per size. Larger instances burn more Run credits per hour, and the Manage instance dialog shows an estimated monthly cost based on your last 30 days. The performance page also says to fix slow queries before resizing, and I agree with it completely. Nine times out of ten, a "we need a bigger database" problem is a missing index on a column the app filters by on every page load. Our free Lovable cost check reads your repo and estimates what your Cloud setup costs against running it on your own Supabase.

When it stops being enough

The Lovable database is fine for a lot of apps that will never outgrow it. We'd move off it when one of these is true: you need to restore to a specific minute, you need an extension that isn't on the list, two projects need to share data (each Lovable project gets its own isolated database), or you need it in a region other than the one picked on day one.

The move is the export above plus everything it leaves behind. Our migration checklist lists every piece. If you'd rather not do it yourself, we do Lovable Cloud to Supabase migrations from $150, priced by table count, usually in 1 to 2 days, and full production hardening for apps that need backups and monitoring set up properly.

Originally published on lovable2live.com. Aakash Verma, software developer and founder of Lovable 2 Live.

Capacitor vs Expo for a Lovable App: Wrap It or Rebuild It

Aakash Verma — Thu, 05 Nov 2026 23:49:18 +0000

For an app built with Lovable, Capacitor is the right default and Expo is the right second choice. Capacitor wraps the React web app you already have in a native iOS and Android shell, so the same code runs in the browser and in both stores and you keep building in Lovable. Expo is a framework for React Native, which means rewriting every screen with native components: more work up front, a more native feel, and you stop editing the mobile app in Lovable.

That's the whole decision in two sentences. The rest of this post is about the cases where the second sentence wins.

What each one actually does

Capacitor (capacitorjs.com) takes your built web app, the dist folder Vite produces, and runs it inside a native WebView. You get real ios/ and android/ projects, real App Store and Play Store builds, and plugins that call native features from JavaScript: camera, push notifications, file system, haptics, biometrics. Your Tailwind classes, shadcn/ui components and Supabase calls work unchanged, because it's still a web page underneath.

Expo (expo.dev) is the most common way to build React Native apps today. React Native doesn't render HTML. A <div> becomes a <View>, text has to sit inside <Text>, and CSS becomes style objects (or NativeWind if you want Tailwind-like classes). Your business logic, Supabase client, types and API calls carry over. Your UI does not. Expo SDK 58 shipped on October 14, 2026, and it comes with Expo Router, cloud builds through EAS and over-the-air updates.

Where Capacitor wins for a Lovable app

You keep one codebase. A change you make in Lovable on Monday is in the web app and, after a rebuild, in both store apps. With Expo you maintain two UIs from then on.
It's faster to ship. Most of the work is native setup, icons, splash screens, permissions and store submission, not rewriting screens.
Lovable keeps working. Lovable generates web React. It doesn't generate React Native, so an Expo app is something you or a developer edit by hand afterwards.

One thing changed in 2026. Lovable projects started since mid-2026 use a server-rendered TanStack Start template instead of a plain Vite single-page app, so npm run build no longer gives you a folder of static files to hand to Capacitor. The app needs a client-only build for its webDir first, which is a config change, not a rewrite. Older Lovable projects build static files as before. Our look at the current Lovable template shows what's inside.

The other catch is Apple's guideline 4.2. A WebView app that's just your website in a box gets rejected for "minimum functionality". Adding real native features (push notifications, the camera, offline screens, native sharing) is what gets it through, and we cover that in the 4.2 rejection guide.

Where Expo wins

The app is mostly gestures and animation. Swipe-heavy feeds, maps with lots of markers, drag and drop, complex lists of thousands of rows. A WebView can do these, but native components do them more smoothly on older phones.
The mobile app is becoming the main product. If most of your users will be on the app and the web version is secondary, paying once for a native UI is a reasonable trade.
You want builds without a Mac. EAS builds iOS apps in the cloud. With Capacitor you build iOS in Xcode on a Mac, or use a cloud CI like Codemagic.

Over-the-air updates aren't a reason to pick Expo on their own: Capacitor has them too, through Capgo, with the same App Store rules on what you may change without review; see Capacitor live updates.

What it costs to go either way

For us the price is the same for both paths: $300, $600 or $1,000 depending on the size of the app, as listed on our pricing page. Capacitor is the default because it keeps your Lovable workflow; a React Native rebuild with Expo is the second path when one of the reasons above applies. If you're not sure which one your app needs, the two paths compared goes through it screen by screen.

If you'd rather skip all of it, we publish your Lovable app to the App Store and Google Play from $300, with the native features Apple asks for.

Originally published on lovable2app.com. Aakash Verma, software developer and founder of Lovable 2 Live.

Lovable App Builder: What It Generates in 2026

Aakash Verma — Tue, 03 Nov 2026 23:53:51 +0000

The Lovable app builder turns a prompt into a working web app, and in late 2026 that app is no longer the simple React page it used to be. New projects start from a template called tanstack_start_ts_current: a server-rendered TanStack Start app with React 19, Vite 8, Tailwind 4 and 46 prebuilt UI components, installed with bun. We know because we made one on October 5, 2026, connected it to GitHub, and read every file.

That matters if you ever plan to host it somewhere else, hand it to a developer, or wonder why a tutorial from last year doesn't match what you see.

What's in the repo

Here is the real tree from our test project, the one we use for GitHub sync tests. The first commit is from Lovable itself: template: tanstack_start_ts_current-01a0e63ae988. After that, commits from gpt-engineer-app[bot] for every change made in the editor.

The parts worth knowing about:

.lovable/project.json holds three lines: a schema version, the template name and its revision. Don't delete it.
AGENTS.md is written for AI coding agents, and its first instruction is blunt: don't force push or rewrite history on the connected branch, because "the user will likely lose their project history." Commits you push sync back into the Lovable editor, so the branch has to stay in a working state.
src/routes/ is file-based routing from TanStack Router, and routeTree.gen.ts is generated from it. Don't edit the generated file by hand, it gets overwritten.
src/server.ts wraps server rendering so a crash returns a readable error page instead of a bare {"unhandled":true,"message":"HTTPError"} 500. Somebody at Lovable got bitten by that and wrote a comment about it.
src/components/ui/ is shadcn/ui: 46 components, Radix underneath, from accordion to tooltip. Most apps use maybe ten of them.
bunfig.toml refuses any package version published less than 24 hours ago (minimumReleaseAge = 86400), with exceptions only for Lovable's own packages. That's a supply-chain guard against hijacked npm releases, and honestly it's a better default than most agencies ship.

There's also Vitest with Testing Library for tests, ESLint and Prettier configs, and a vite.config.ts that is almost empty because everything comes from @lovable.dev/vite-tanstack-config. A comment in that file warns you not to add the TanStack, React or Tailwind plugins yourself "or the app will break with duplicate plugins". Believe it.

It's a server app now

Projects from before mid-2026 were single-page apps: Vite built a folder of static files and any static host could serve it. The current template renders pages on a server. The build goes through Nitro, and the config's default target is Cloudflare.

Two consequences. Google gets real HTML for each page, which is good news for the SEO problems older Lovable apps had. And "just upload the dist folder to Netlify" stops working. We've watched a founder do exactly that and get a site that loaded the shell and nothing else, because there was no server to render the routes. You need a host that runs the server build (Cloudflare, Netlify or Vercel with the right Nitro preset, or a Node server), and environment variables have to exist at runtime as well as at build time.

What the builder still leaves to you

The code is clean and the stack is modern. That's not the problem. What the builder doesn't decide for you is everything around the code:

where the backend lives (Lovable Cloud by default, or a Supabase project you own; newer TanStack Start apps can use your own Supabase from the start),
whether the row level security policies actually stop one user reading another user's data,
which secrets ended up in client code,
what happens to your app when the credits run out.

That last one surprises people. On Lovable Cloud, the backend pauses shortly after your balance hits zero, so sign-in stops working until you top up. Our free Lovable cost check reads your repo and tells you what the app costs to run each month, and what it would cost on your own Supabase.

Should you care which framework it is?

If you only ever build in the editor, barely. If you'll ever hire a developer, yes: tell them it's TanStack Start, not Next.js and not a plain Vite SPA, before they quote. Half the estimates we see for "Lovable to production" work are priced for the wrong stack.

When it's time to take a Lovable app live properly, we do Lovable to production at a fixed price from $500, usually in 5 to 7 days, working in your existing repo so you keep building in Lovable. If the app is on Lovable Cloud and you want the database in your own name, the move to Supabase starts at $150.

Originally published on lovable2live.com. Aakash Verma, software developer and founder of Lovable 2 Live.

Capacitor Live Updates for a Lovable App: Capgo and the Rules

Aakash Verma — Mon, 02 Nov 2026 23:54:36 +0000

A Capacitor app is your Lovable web build sitting inside a native shell. That's why live updates work at all: when you change a button label in Lovable, the thing that changed is a folder of HTML, CSS and JavaScript, and a live update service can download that folder to your users' phones on the next launch. No App Store review, no waiting a day for Google. For a founder who keeps building in Lovable after launch, it's the difference between fixing a typo today and fixing it next Thursday.

There are limits, though, and one of the big tools just went away.

Appflow is closing, so it's Capgo or Capawesome

For years the default answer was Ionic Appflow. On February 11, 2025, Ionic stopped selling Appflow to new customers, and existing customers keep access until December 31, 2027. If a tutorial tells you to sign up for Appflow, it's out of date.

The two services people actually pick now are Capgo and Capawesome Cloud. We default to Capgo for small Lovable apps because the plugin is open source and the pricing is easy to read. Capgo's pricing page, checked November 1, 2026:

Plan	Monthly	Billed yearly	Monthly active users	Bandwidth
Pay as you go	$0, credits only ($5 to start)		per use	per use
Solo	$14	$12	2,000	100 GiB
Maker	$39	$33	10,000	1,000 GiB
Team	$99	$83	100,000	10,000 GiB

Over the limits it's $0.003 per extra monthly active user and $0.06 per GiB of bandwidth to start. A typical Lovable bundle compresses to a few megabytes, so for an early app the user count decides the plan, not the bandwidth.

What can ship as a live update, and what can't

Anything that only touches the web build can go out live. Copy changes, a broken form, a new screen built from components you already have, a Supabase query that was fetching too much. That covers most of what founders change in Lovable week to week.

Anything native needs a new build through the stores:

a new Capacitor plugin (camera, push, purchases), because the native code has to be compiled in,
a new permission string in Info.plist or AndroidManifest.xml,
the app icon, splash screen or app name,
a Capacitor major version upgrade.

Then there's the rule side. Apple's App Review Guideline 2.5.2 says apps may not download code that "introduces or changes features or functionality", and the developer agreement only allows downloaded interpreted code that doesn't change the app's primary purpose. In practice, fixes and small improvements through a live update are fine, and every serious Capacitor team ships them. Turning a habit tracker into a dating app overnight is not. If the change would surprise the reviewer who approved your last version, send it through review.

Google Play is looser for JavaScript running in a WebView, but the same common sense applies.

Setting it up on a Lovable app

The short version, with Capgo:

Install the plugin in the Capacitor project: npm i @capgo/capacitor-updater, then npx cap sync.
Call CapacitorUpdater.notifyAppReady() as soon as the app has loaded. This one matters. If the app doesn't call it within the timeout after an update, the plugin assumes the new bundle is broken and rolls back to the last good one. That rollback is the safety net, so don't skip it.
After each change in Lovable, pull the code, run the web build, and upload it: npx @capgo/cli bundle upload. You can put that in a GitHub Action so a merge to main ships it.
Bump a store release only when one of the native changes above happens.

We had a founder whose first live update went out with the production Supabase URL swapped for the staging one, because the build ran with the wrong .env. The rollback didn't fire, since the app loaded fine and called notifyAppReady(). It just loaded an empty database. Thirty minutes later the fixed bundle was out, which is the point of live updates, but it's also why we upload to a test channel first and promote to production after checking it on a real phone.

Is it worth paying for?

If you change the app once a month, no. Ship store releases; Apple's review usually takes a day or so. If you're still building in Lovable several times a week after launch, yes, and $14 a month is less than the time you lose waiting on review for a typo.

Live updates are also one of the reasons we build Lovable apps with Capacitor first: the founder keeps prompting in Lovable and the phones get the change the same day. If you want that set up properly, our Lovable app publishing service takes your Lovable app to the App Store and Google Play from $300, and the App Store rejection fix is $350 flat if Apple has already said no.

Originally published on lovable2app.com. Aakash Verma, software developer and founder of Lovable 2 Live.

Lovable MCP: Three Things With One Name

Aakash Verma — Sun, 01 Nov 2026 23:57:23 +0000

"Lovable MCP" is three different features in Lovable's docs right now (checked October 29, 2026), and people mix them up constantly. The Lovable MCP server at https://mcp.lovable.dev lets an AI client like ChatGPT, Cursor or VS Code drive your Lovable projects. Chat connectors go the other way: Lovable's agent reads from your MCP servers while it builds. And agent integrations turn your published app into an MCP server that other people's assistants can call.

They point in different directions, they cost different things, and only one of them touches your live users.

	Who calls whom	Plans	What it costs
Lovable MCP server	Your AI client calls Lovable	All plans	Normal credits for every message and build it triggers
Chat connectors (custom MCP)	Lovable's agent calls your tools while you build	All plans	Nothing extra to connect; it's context for builds
Agent integrations	Someone's assistant calls your published app	All plans for public apps	Build credits to set up, then normal backend and AI usage per call

1. The Lovable MCP server: driving Lovable from somewhere else

This is the one most searches mean. Lovable runs an MCP server at https://mcp.lovable.dev, login is OAuth, and it's on by default for Free, Pro and Business workspaces (Enterprise admins have to switch on "Third-party MCP clients" first). In ChatGPT you paste the URL; in Cursor and VS Code it's a few lines in mcp.json; Claude Code has a one-line mcp add command. The Lovable MCP server docs have the exact config for each.

Once connected, your client gets about forty tools. The useful ones: create_project, send_message (with a plan_mode switch), get_diff, list_files, read_file, list_edits, deploy_project, get_project_analytics, and three database tools, get_database_status, enable_database and query_database.

Where it's genuinely good: reading code and diffs without opening the editor, asking for three layout variants and getting three live URLs back, and pulling analytics into the same chat where you're already working. I like get_diff most. Being able to ask "what did the last three prompts actually change" and get a unified diff is the review step Lovable never had.

Read Lovable's own warning box before you connect it, because it's blunt for a reason:

The connection isn't limited to one project. It can reach every workspace your account can.
Tool calls spend real credits. An agent that loops on send_message because it doesn't like the result will burn through a month's credits while you're making coffee. Same credit pool as the editor, same prices.
deploy_project publishes for real. On Free and Pro, anyone with the link can open the app unless website access is set to invite only.
query_database runs SQL with your full database permissions. Reads, writes, drop table.

My rule: the MCP server is fine for building and reviewing. I wouldn't hand query_database on a production project to any agent that runs without a human reading each call.

One more detail that surprises people. The database tools only work on Lovable's built-in Cloud database. If the project uses your own Supabase project, Lovable's docs say it's "managed in Supabase instead", so you'd connect Supabase's own MCP server for that. That's one of the small reasons teams move from Lovable Cloud to their own Supabase: the database becomes something every tool can reach, not just Lovable.

The MCP server is also the only way to create and edit projects from outside. The Lovable API can publish, embed and read analytics, but it can't send a prompt.

2. Chat connectors: Lovable reading your tools

The second "Lovable MCP" is the reverse. You give Lovable's agent access to a remote MCP server (Notion, Linear, Jira, or your own) so it builds from real context: "use the spec in the Notion page" instead of you pasting it.

Custom MCP servers work on all plans. You add them under Connectors, Add custom, MCP server; auth is OAuth by default, or a bearer token, or none. If your server sits behind a firewall, there's a "Lovable static IPs" option that routes traffic from 185.41.150.0/28 and 185.41.150.16/28 so you can allowlist them. Details are on the custom MCP page.

The trap: chat connections are personal and "never part of your published app." Connecting your CRM as an MCP server doesn't let your app read the CRM. That needs an app + chat connector, a different feature with different credentials. It's an easy mistake to make, because the agent uses the connector perfectly in chat, and then the live app still can't see a thing.

3. Agent integrations: your app as an MCP server

The newest one, and the one I'd slow down on. Lovable can turn a published app into an MCP server: it reads your app, proposes tools like list_open_requests or generate_quote, asks whether callers must sign in, and gives you an MCP link users add to ChatGPT or another assistant. The agent integrations docs cover the setup.

Lovable doesn't charge for hosting the integration or for tool calls. Enabling it is a build, so it uses build credits, and every call after that costs what the action behind it costs: database reads, Cloud usage, AI calls. Free and Pro apps have to be published publicly to get one. Sign-in needs real app auth, and on newer TanStack Start apps with your own Supabase project, Lovable turns on Supabase's OAuth 2.1 server when you publish.

Then there's this line from the docs, which is the whole reason this section exists: agent integrations "do not include a built-in rate limit or spending cap."

Think about what that means for a tool that calls an AI feature. A person clicks a button a few times. An assistant in a retry loop calls generate_quote a few thousand times, and every call runs your real backend and your real AI usage on your credits. If the tool is open to anyone, it doesn't even need an account to do it.

Before I'd switch one on for a live app:

Start with read-only tools. Nothing that writes, sends email or charges a card.
Require sign-in unless the data is already public on your site.
Put a per-user limit in the backend function itself, because nothing else will.
Make every write safe to run twice, since assistants retry.
Check that each tool enforces the same RLS policies and plan checks as the screen it replaces. Lovable proposes tools from what the app does, not from who's allowed to do it.

That last one is exactly what we look at in a Lovable security audit: an app that's safe through its own screens can be wide open through a second door nobody tested.

Which one did you actually want?

If you want to build or review Lovable projects from ChatGPT, Cursor or VS Code, it's the MCP server. If you want Lovable to read your docs and tickets while it builds, chat connectors. If you want your customers to use your app from inside their assistant, agent integrations, with limits you add yourself.

And if the credit side of any of this worries you, our free Lovable cost check reads your repo and prices the app four ways, including running it outside Lovable. For the app itself, tell us what you're building.

Originally published on lovable2live.com. Aakash Verma, software developer and founder of Lovable 2 Live.