DEV Community: Aakash Verma

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.

RevenueCat Pricing for a Lovable App

Aakash Verma — Sat, 31 Oct 2026 23:58:37 +0000

RevenueCat costs nothing until your app tracks $2,500 of revenue in a month. From that month on it charges 1% of everything it tracked, not 1% of the part above $2,500, and it measures that revenue before Apple or Google take their cut. That's from RevenueCat's pricing page, checked October 29, 2026, and those three details are the whole story.

If your Lovable app sells subscriptions or credits inside the iPhone app, you're going to meet RevenueCat. Apple wants digital goods sold through in-app purchase (we covered when Stripe is still allowed), and RevenueCat is the usual way to know who's paying across Apple, Google and the web without writing two webhook pipelines yourself. So it's worth knowing what it really costs before you wire it in.

What "monthly tracked revenue" counts

RevenueCat's own definition: MTR is "the amount of revenue tracked by RevenueCat (in USD, before the platform cut) during a one-month billing period. This includes paid subscriptions, renewals, and one-time purchases."

Two things fall out of that.

It's gross. A $9.99 subscription counts as $9.99 even though Apple pays you $8.49 of it on the Small Business Program. RevenueCat says this is deliberate: they don't want to be paid less when they help you move people to cheaper platforms, Stripe included.

And it's everything you route through it. If you connect your Stripe web subscriptions so the app knows about them too, those dollars are tracked revenue as well. Handy for one "is this user Pro?" answer. Not free.

The $2,500 cliff

Here's the line from their FAQ that people skim past: "Once you reach $2.5K MTR, you'll be charged 1%. For $2.5K, we'll charge you $25. No charges apply on months when you don't hit the $2.5K threshold."

So it's not a free allowance with 1% on top. It's a switch. A month at $2,499 costs $0. A month at $2,500 costs $25.

Honestly, I don't think the cliff matters much. $25 when you're making $2,500 a month is fine. But it does mean a month that hovers right around the line can cost you $25 for a few extra dollars of sales, so don't be surprised when it shows up on the invoice.

What it costs at real numbers

Assume a subscription app on Apple's Small Business Program (15% instead of 30%, for developers under $1 million a year, see our post on the program). Everything below is per month.

Tracked revenue	RevenueCat	Apple's 15%	You keep	RevenueCat as a share of what you keep
$1,000	$0	$150	$850	0%
$2,499	$0	$374.85	$2,124.15	0%
$2,500	$25	$375	$2,100	1.19%
$10,000	$100	$1,500	$8,400	1.19%
$50,000	$500	$7,500	$42,000	1.19%

Because the fee is on gross revenue, it's a bit more than 1% of what actually lands in your bank: about 1.19% at the 15% rate, about 1.45% if you're paying Apple 30%.

Everything is included on that plan: paywalls you can change without an app update, A/B experiments, charts, webhooks, integrations. Enterprise is custom pricing for big apps. There's also a separate "Growth Tools" option where you keep your own purchase code and pay 1% only on conversions that come through their paywalls or web funnels.

Wiring it into a Lovable app

For a Lovable app shipped with Capacitor, the plugin is @revenuecat/purchases-capacitor. You configure it once at startup with the platform's public API key (iOS and Android have separate ones) and, this is the bit people skip, the Supabase user id as appUserID. If you let RevenueCat invent anonymous ids, your webhooks arrive with ids your database has never heard of, and someone ends up writing a matching script at midnight.

Then don't make your app ask the SDK "is this user Pro?" on every screen. Point a RevenueCat webhook at a Supabase edge function, write the entitlement and its expiry into a column on the user's profile, and let your RLS policies read that column. The web version of your app, which never loads the SDK, gets the same answer for free.

Products still have to exist in App Store Connect and Google Play Console first, with tax and banking done, and Apple reviews each new subscription together with an app build. RevenueCat can't skip any of that.

Should you build it yourself instead?

You can. Apple's App Store Server Notifications and Google's real-time developer notifications both hit a webhook you control, and a Supabase edge function can keep the same entitlement column up to date. No percentage.

I wouldn't, below a fairly large number. Renewals, grace periods, billing retry, refunds, upgrades between tiers, family sharing, two stores with two different payload formats: every one of those is a bug you'll find in production. Under $2,500 a month RevenueCat is free, which makes the decision for you. At $10,000 it's $100 a month, which is less than an afternoon of a developer's time spent on the first refund bug. Somewhere well past that, writing your own starts to make sense, and by then you'll have the revenue to pay for it.

The one thing I don't love: your source of truth for "who paid" now lives at a third company. The webhook-into-Supabase pattern above is how we keep that from mattering day to day.

If your Lovable app is about to go into the App Store with subscriptions and you'd rather not set up products, the SDK and webhooks yourself, that's part of taking a Lovable app to the App Store with us. Or ask us anything first.

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

Lovable vs Claude Code: Which One Fits Your App?

Aakash Verma — Fri, 30 Oct 2026 23:34:51 +0000

Lovable vs Claude Code isn't really one tool against another. Lovable is a whole place to build and run an app: the chat, the preview, the hosting and a Supabase backend, all behind one login. Claude Code is a coding agent. It edits a repository and opens a pull request, and everything around that repository is your problem. Which one fits depends far less on how smart the AI is and far more on whether you want to own the rest of the stack.

We checked both on October 28, 2026: Lovable's pricing page and docs, and the Claude pricing page and the Claude Code cloud sessions docs.

What you pay

Lovable Pro is $25 a month for 100 credits, and top-ups cost $15 per 50, so a credit works out to about $0.30. A message in Plan mode costs 1 credit. In the default mode it depends on the work: Lovable's own examples run from 0.50 for a style change to 1.70 for a landing page with generated images. Hosting and the backend come out of the same balance once your app outgrows the free monthly Cloud grant.

Claude Pro is $20 a month ($17 on annual billing) and includes Claude Code, in the terminal and in the browser (Claude Code on the web). There's no per-message price. Instead you get usage limits: a five-hour session window plus weekly limits, and the cloud machine your session runs on doesn't cost extra. If you hit the limits every day, Max starts at $100 a month.

So for someone who builds a lot, Claude Code is cheaper per change, by a wide margin. But that $20 buys you nothing to run the app on. Add hosting (Cloudflare, Vercel, Netlify, or your own server with Coolify) and a Supabase project, which is free to start and $25 a month on Pro.

What each one actually does

In Lovable you describe a change, it edits the code, and the preview updates in a few seconds. You click Publish and it's live. You never see a terminal. The backend (database, auth, storage, edge functions) is Supabase, either Lovable Cloud or your own project, and Lovable writes the migrations for you.

Claude Code on the web works like this: you connect GitHub, pick a repo, describe the change, and Claude works in a cloud machine that clones your repo. It can install packages, run your tests and run a build, which is something Lovable's chat can't really do for you. When it's done it pushes a branch and you open a pull request. Then nothing happens until you merge it and something deploys it.

That last sentence is the whole difference for a non-technical founder. With Claude Code you need a deploy pipeline that turns a merged pull request into a live site, and ideally a preview link for every pull request so you can click around before you merge. Coolify does both. Vercel and Netlify do both. Setting it up is a one-time afternoon for a developer and a confusing week for someone who has never seen a build log.

The other thing you lose is the visual editor. Lovable's Visual Edits let you click a heading and change it. In Claude Code you describe it, wait, and check the preview. Faster for big changes, slower for "make this button blue".

Where Claude Code wins

Big refactors. Anything across 30 files. Writing tests and actually running them. Upgrading a dependency and fixing what breaks. Lovable can do some of this, but you pay per message and you can't see the test output, so you end up asking "did that work?" and paying again for the answer.

Claude Code also doesn't care how your app is built. Lovable is React, Vite, Tailwind and Supabase, and it is very good inside those lines. Claude Code will work on a Next.js app, a Laravel API or a Python worker in the same afternoon.

We had a founder who'd spent close to 400 credits over two weeks trying to get Lovable to fix a date bug in a booking calendar. Timezones, of course. Every fix broke a different week view. A developer with Claude Code wrote 14 tests for the calendar first, ran them, and the agent fixed the bug in one session because it could see which tests failed. The tests are still in the repo.

Where Lovable wins

Starting. Nothing gets you from an idea to a working app with login and a database faster, and the preview loop is great for people who think visually. If you're still figuring out what the product is, paying per credit is fine. You're paying for speed, not code.

It's also one bill and one login. No hosting account, no Supabase dashboard, no environment variables in three places. For a founder that's worth real money.

Using both on one repo

This is what we see most often now, and it works if you respect one rule: Lovable commits straight to its synced branch and doesn't open pull requests. Claude Code works on its own branch and opens one. So let Lovable keep main, have Claude Code work on branches, and merge its pull requests into main when you're not mid-edit in Lovable. Lovable picks up the merged code from GitHub.

Two things bite people. First, don't edit the same files in Lovable while a Claude Code branch is open, or you'll get merge conflicts that neither the chat nor you will enjoy. Second, if GitHub offers to delete a branch after a merge, make sure it isn't the one Lovable syncs to. If it is, Lovable quietly starts committing to a lovable-fallback branch instead. (Our Lovable GitHub sync post has the fix.)

If your app is on Lovable Cloud, the backend can't follow you to Claude Code without a move: Lovable Cloud's Supabase project isn't in your Supabase account, so a coding agent outside Lovable can't run migrations on it. That's what our Cloud to Supabase migration is for, from $150, done in 1 to 2 days.

So which one?

Keep Lovable while you're still shaping the product and you build in short bursts. Move the daily building to Claude Code when your credit spend keeps climbing past the price of Claude Pro plus hosting, when you need tests, or when a developer joins. And put the numbers in before you decide: our free Lovable cost check reads your repo and shows what your bill would be on your own Supabase, on your own server, and with Claude Code on the web instead of Lovable, side by side.

If you want that switch set up once (server, previews on every pull request, the workflow), book a call and we'll walk through your app.

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

How Long Does App Store Review Take? (2026)

Aakash Verma — Thu, 29 Oct 2026 02:29:44 +0000

Apple's own number: App Review "typically" reviews at least 50% of submissions in less than 24 hours and 90% in less than 48 hours, and it works around the clock. That's from Apple's App Review page, checked October 26, 2026.

So the review itself is fast. What makes a first launch take a week or more is everything around it: the rejection you didn't plan for, the resubmission, and on Android a testing rule that has nothing to do with review speed at all.

The Apple clock, honestly

Those 24 and 48 hour figures measure one submission, from "Waiting for Review" to a decision. They don't include the time before you can submit (screenshots, privacy labels, the App Review Information section with a demo login) or what happens after a rejection.

And a rejection restarts the queue. You fix the issue, upload a new build or edit the metadata, resubmit, and wait again. One or two rejections on a first submission isn't unusual for a wrapped web app, and that turns "under 48 hours" into most of a week without anyone at Apple being slow.

Apple says on the same page that over 40% of unresolved issues fall under guideline 2.1, App Completeness: crashes, placeholder content, broken links, missing info. For an app built in Lovable and wrapped with Capacitor, the two we'd check first are:

The reviewer can't log in. If your app needs an account, put a working demo login in App Review Information. Make sure it doesn't hit an email confirmation step, a magic link, or a Supabase auth setting that only works on your domain.
It's a website in a box. That's guideline 4.2, Minimum Functionality, the classic Lovable rejection. We wrote a whole post on fixing a 4.2 rejection, because it's the one that eats the most days.

Can you speed it up?

Sometimes. Apple has an expedited review request for two cases: fixing a critical bug in a live app (include steps to reproduce it on the current version), or a release tied to an event you're directly associated with (include the event and the date). It's a request, not a button, and "my investor demo is Friday" isn't on the list.

There's also a small mercy for bug-fix updates: if App Review finds other issues while reviewing a bug fix, they can offer to approve the current submission and let you fix the rest in the next one, as long as nothing is legal or safety related. Reply to the offer message in App Store Connect to take it.

What actually saves the most time is boring: submit something finished. No "coming soon" screens, no lorem ipsum in a settings page, no buttons that go nowhere.

TestFlight first

If you plan to test with outside users before launch, external TestFlight testing needs its own Beta App Review for the first build. It's usually quick, but it's another review in the timeline, so start it early. Our TestFlight guide covers the setup.

Google Play is a different kind of slow

Google's review of a normal update is usually quick too, but its help center warns that "certain developer accounts" get extended reviews of up to 7 days or longer in exceptional cases, see Google's page on preparing your app for review.

The bigger wait is a rule, not a queue. If your Play Console account is a personal account created after November 13, 2023, you must run a closed test with at least 12 testers who stay opted in for 14 days in a row before you can even apply for production access (Google's testing requirements). Then you answer questions about the test, and then the app gets reviewed.

So for a new founder with a new personal account, the realistic Android timeline is about three weeks, and no amount of polish changes that. An organization account (which needs a D-U-N-S number) skips the closed test requirement, so if you're a registered company, it's worth setting the account up that way from the start. We'd plan the two stores in parallel: start the Android closed test the same week you submit to Apple.

The timeline we'd plan for

For a first launch of a Lovable app on both stores:

Apple: a week, counting one rejection and a resubmission. Often less.
Google Play, new personal account: three weeks, mostly the 14-day closed test.
Every update after that: a day or two on Apple, usually hours to a couple of days on Play.

If Apple has already rejected you and you just want it through, our App Store rejection fix is $350 flat and we resubmit within 3 days. If you haven't submitted yet, we can publish the app for you on both stores.

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

How to Reduce Your Lovable Cloud Bill

Aakash Verma — Wed, 28 Oct 2026 00:03:31 +0000

To reduce your Lovable Cloud bill, open the project's More → Usage view first and find the biggest category: Database, AI, Compute, Network, Storage or Realtime. Then fix that one. In most projects we look at it's the database server, and the cheapest fixes are pausing backends that never sleep, picking a smaller instance size, and deleting old files, all from More → Database → Manage → Settings (Lovable's project usage docs, checked October 22, 2026).

Cloud usage is billed in run credits, from the same balance you build with. Free, Pro and Business workspaces get a 20-credit monthly Cloud grant and a 4-credit monthly AI grant first. Lovable calls both a temporary offering. Everything past them comes out of your general credits.

What the docs leave out (checked October 27, 2026): those credits cost real money. On Pro a top-up is $15 for 50 credits, so every run credit past the 20-credit Cloud grant is worth about $0.30, and a backend that uses 120 run credits a month eats about $30 of credits you could have built with. If the database server is still the biggest line after the fixes below, the other way to cut the bill is to move the backend out of Lovable Cloud: a Supabase Pro project is $25 a month with a Micro instance included, and your app traffic stops spending Lovable credits. We do that move for $150, $350 or $600 one time, by table count, usually in 1 to 2 days (Cloud to Supabase migration). The free Lovable cost check runs those numbers for your own project.

Find what you're actually paying for

Don't start by resizing anything. The Usage view splits a project's run credits by category and sorts them from highest to lowest, with the last 30 days by default and up to 90. It also shows how much of that your monthly grants covered.

If a project burned more than 5 run credits in the last 7 days, workspace owners and admins get an Optimize your usage button under the chart. It starts a chat where Lovable reads the project's recorded usage and suggests fixes. It's worth one message. Just read what it proposes before you approve anything, because "resize the instance" is an easy answer and not always the right one.

Database: the usual culprit

The database server line depends on the instance size and how long it runs. Paid plans can pick Tiny, Mini, Small, Medium, Large or X-Large, and the Manage instance dialog shows an estimated monthly cost under each size, based on your last 30 days of usage (database size docs).

Two things to know before you touch it. A resize restarts the instance, so there's a short interruption. And if your project sits on 2X-Large, that size can't be picked again once you move off it. So step down one size at a time, on a quiet hour, and watch the app for a day.

Often the instance isn't too big, it's doing too much work. A dashboard that runs eight queries per card, a list that loads every row and filters in the browser, a missing index on the column every page filters by. Ask Lovable to find the slowest queries before you pay for a bigger box. We've seen projects move up two sizes to hide a single unindexed user_id filter.

Backends that never go to sleep

Lovable pauses a project's backend automatically after about 7 days without activity. The catch: projects with scheduled jobs or other background activity don't count as inactive, so they never get paused (pause docs). That old prototype with a nightly cron job is running every hour of every day.

Pause it yourself from Database settings. Your data stays, and you can wake it up later. Be aware that while it's paused the published app can't sign anyone in, read data or serve files, and edge functions for payments, AI or email stop too.

If a project doesn't need a backend at all anymore, Remove database stops every Cloud charge for it. It also deletes the database, its backups, the user accounts and every stored file, permanently. Export first.

Storage keeps billing while you sleep

Stored files count against your credits even while a project is paused. Old uploads, test images, generated files nobody opens: delete them. If your app serves big images, resize them on upload instead of sending the original to every visitor, because the same file then costs you twice, once in Storage and again in Network every time it loads.

Jobs, compute and AI

Scheduled jobs add up quietly. A job every minute is 43,200 runs a month. Check the project's Jobs and ask whether each one really needs that schedule.

On the AI side, the AI gateway charges by model and tokens. Long chat histories sent on every message, a big model for a yes/no classification, a whole document pasted into each prompt: those are the usual leaks. Use a smaller model where the answer is simple and trim what you send.

Put a cap on it

On paid plans, owners and admins can set limits in Workspace settings → Usage limits & alerts (usage limits docs). A limit can watch Run, Cloud or AI credits for one project, per day or per month, and either alert you or pause Cloud when it's reached. Set an alert-only limit at about twice your normal month on every live project. A blocking limit on a production app means the app pauses when it hits it, so think hard before turning blocking on there.

When the bill is still too high

At some point you're paying Lovable to run a database you could run yourself. Once a project's Cloud spend is steady and real, moving the backend to your own Supabase project, or the whole app to your own server, is often cheaper, and you keep building in Lovable either way.

Our free Lovable cost check reads your GitHub repo and shows what your app would cost on Lovable Cloud, on your own Supabase and on a server, side by side. If moving wins, Lovable Cloud to Supabase starts at $150, fixed price, and your own server is $500 plus that move.

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

Apple Developer Account Cost in 2026

Aakash Verma — Mon, 26 Oct 2026 23:51:42 +0000

An Apple developer account costs $99 a year. That's the Apple Developer Program membership, and it's the only way to put an app on the App Store; Apple's enrollment page (checked October 24, 2026) says prices may vary by region and are shown in local currency when you pay. Google Play is $25, once, per the Play Console help. So publishing one Lovable app on both stores costs $124 in the first year and $99 every year after that.

The fee is the easy part. What actually slows founders down is picking the wrong account type.

Individual or organization?

Apple gives you two ways to enroll, and the price is the same.

As an individual, you need an Apple Account with two-factor authentication and your legal name and address. Fast and simple. The catch: your personal legal name becomes the seller name on your App Store page. A founder we helped this spring launched a meditation app as an individual, then spent two weeks trying to get "Daniel K. Morrison" off the listing once the company existed. You can convert later, but it's a support ticket, not a setting.

As an organization, you need:

a legal entity that can sign contracts (Apple says no DBAs, trade names or branches)
a D-U-N-S Number, which is free in most countries (check yours here)
a work email on your company's domain
a public, working website on that domain (a social media page or a parked domain gets rejected)
legal authority to bind the company

If you already have a company, enroll as the organization from day one. The website rule catches more Lovable founders than anything else on that list, which is a bit funny when your product is literally a website builder: publish the landing page on your own domain before you apply.

Nonprofits, accredited schools and government bodies can ask for a fee waiver. The $299 Apple Developer Enterprise Program is something else entirely, for internal company apps that never go on the App Store. You don't want it.

The Google Play side

$25 one time, card only (no prepaid cards), plus ID checks. The real cost is time: personal Google Play accounts created after November 13, 2023 must run a closed test with at least 12 testers who stay opted in for 14 days in a row before production access opens. Testers who drop out early don't count. That rule doesn't apply to organization accounts, which is another reason to set up the company first.

What happens if you stop paying Apple

Apple's renewal page is clear: when the membership expires, your apps are no longer available for download and you can't submit updates. People who already installed the app can keep using it. Renew, and free apps come back within 24 hours without a resubmission; paid apps come back after you accept the Paid Applications Agreement again.

So put the renewal on a company card that won't expire. We've seen a live app vanish from the App Store for four days because the card on the founder's personal Apple Account was replaced after a fraud alert.

What $99 doesn't buy

The account lets you submit. It doesn't make a Lovable app acceptable to Apple. A web app wrapped in a WebView with no native features gets rejected under guideline 4.2, and that's where most first submissions die. Budget for:

the Capacitor build itself, plus icons, splash screens and the screenshots App Store Connect wants
native features Apple can see (push notifications, camera, offline storage)
a reviewer demo login and an in-app account deletion option, both required
a Mac with Xcode, or a cloud build service, to produce the iOS build

If you'd rather not learn Xcode for one app, we publish Lovable apps to the App Store and Google Play at fixed prices from $300, and if Apple has already rejected yours, our App Store rejection fix is $350 flat. Either way you pay Apple's $99 yourself, on your own account. Never let anyone publish your app under theirs.

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

Migrate Lovable Cloud to Your Own Supabase

Aakash Verma — Mon, 26 Oct 2026 00:03:03 +0000

To migrate a Lovable Cloud app to your own Supabase project, you export the database from Lovable, restore it into a new Supabase project, carry the storage files, edge functions and secrets across by hand, then remove Lovable Cloud and connect the new project to the same Lovable project. Lovable's own docs put it plainly: "There is no automatic migration between the built-in backend and your own Supabase project, in either direction." (checked October 23, 2026, Supabase integration docs).

So it's a manual job, but a well-defined one. Here's how the five stages go, and where they go wrong.

1. Export the database

The export moved in Lovable's UI this year. It now lives under More, Database, Manage, Settings, as "Export project data". You start it, Lovable emails you when the file is ready, and you download it from More, Storage. The details from the database backups docs:

it's a compressed PostgreSQL archive, loaded with pg_restore, with your full schema and data, auth users and their password hashes included
databases up to 15 GB, an export file of at most 5 GB, one export every 24 hours
the database has to be running, so a project paused for zero credits gets woken up first
removing the database deletes the export too, so download it before anything else

What it leaves out is the list that matters: files in storage, edge function code, secrets, sign-in provider settings and API keys.

2. Create the Supabase project and restore

Make the project in your own Supabase organization, on the region your users are closest to. Then restore the archive with pg_restore.

Lovable's docs suggest a different route: connect the new project and ask Lovable to rebuild the schema. I don't like it. A rebuilt schema is the AI's reading of your code, not your database. Policies, triggers and functions that the code doesn't mention don't come back, and you still have to load the data into whatever it built. The archive is the real thing. Restore that.

A straight restore has its own trap, though. It leaves the public anon role with more access to tables and functions than it had on Cloud. Nothing breaks, so nobody notices, and the app is now less private than it was the day before. Check the grants before the app talks to the new database.

3. Move what the export left behind

This is the part that takes the time.

Storage files. The export has the bucket records, not the files. Every file has to be downloaded and uploaded again with its path intact. On one migration we rehearsed the whole thing on a throwaway project first and still got caught here: image URLs saved in a table pointed at the old Lovable Cloud host. They kept working, right up until Cloud was removed, and then every image in the app 404'd.

Edge functions. The code is in your repo, so it deploys again with the Supabase CLI. Check each function's verify_jwt setting while you're at it.

Secrets. You can see their names in Lovable, never their values. Stripe, OpenAI, Resend and the rest have to be re-entered from the providers' own dashboards. Make the list before the cutover, not during it.

Sign-in. Lovable's managed Google login doesn't follow you. You need your own Google OAuth client, published "In production", plus redirect URLs, email templates and SMTP set again in the Supabase dashboard.

4. Remove Cloud and connect

Linking a Supabase organization to a Lovable workspace needs a workspace owner or admin. After that, anyone with edit access can connect the project. Lovable's Cloud settings have the option to remove Cloud from the project. Then the same project connects to your Supabase project, and you keep building in Lovable as before.

Two things catch people here. The published site keeps talking to the old backend until you republish. And supabase/config.toml in the repo still names the old project, so the next edge function deploy can go to the wrong place.

5. Check before you tell anyone

Count rows table by table against the old backend, sign in as a real test user (with a password and with Google), open a few uploaded files, and trigger every email the app sends. Users who were signed in at the switch have to sign in again. Plan the cutover for your quietest hour.

How long it takes

A small app (under 10 tables, a few hundred users, one bucket) is a day of careful work if you know Postgres. Most of that day is stages 3 and 5, not the export. If you don't know what pg_restore --list prints, or what a grant is, it's longer, and the mistakes are the quiet kind.

We do this as a fixed-price job: Lovable Cloud to Supabase migration, $150 to $600 by table count, usually done in 1 to 2 days, and you keep building in the same Lovable project. If you're not sure the move is worth it yet, the Lovable cost check shows what your app would cost on Cloud and on your own Supabase, side by side. For the full list of what moves and what breaks, there's our migration checklist.

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

In-App Purchases in a Lovable App: Stripe or Apple?

Aakash Verma — Sun, 25 Oct 2026 00:04:52 +0000

If your Lovable app sells a subscription or unlocks features, the web version can keep using Stripe, but the iPhone app usually can't. Apple's guideline 3.1.1 says that to "unlock features or functionality within your app", like subscriptions or premium content, "you must use in-app purchase". The one big exception since 2025 is the United States storefront, where apps may link out to their own checkout. Everything below was checked against Apple's App Review Guidelines on October 23, 2026.

This catches Lovable founders more than most, because the web app already works. Stripe Checkout opens, the webhook flips is_pro in Supabase, done. Then the same flow ships inside a Capacitor app, and the review comes back citing 3.1.1.

What actually counts

Apple cares about what is being sold, not how.

Digital things used inside the app need in-app purchase: subscriptions, credits, premium features, content. A Lovable SaaS with a Pro plan is squarely in this group.

Physical goods and real-world services don't: a shop selling t-shirts, a booking app for haircuts, a marketplace taking a cut of a delivery. Keep Stripe for those, inside the app too.

Things bought elsewhere can be used in the app. Under 3.1.3(b), someone who subscribed on your website can sign in on the iPhone and get Pro, as long as the subscription is also available as an in-app purchase in the app. That last condition is the one people skip.

And the US exception: on the US storefront, guideline 3.1.1(a) now says entitlements "are not required" for buttons and external links to other ways to pay. So a US-only app can show "Upgrade on our website" and send people to Stripe. In every other storefront that button is still a rejection unless you hold Apple's External Purchase Link entitlement where it's offered. Most Lovable apps sell worldwide, so most of them need in-app purchase anyway.

What each option costs

On a $9.99 a month subscription:

Stripe on your website: 2.9% + 30¢ per US card payment (Stripe pricing), so $0.59, and you keep $9.40. Stripe Billing adds 0.7% if you use it for the subscription logic.
Apple in-app purchase: 15% if you're in the App Store Small Business Program (under $1 million in proceeds the year before, and new developers qualify), so you keep $8.49. Above $1 million it's the standard 30%. You have to apply for the 15%; it isn't automatic.
Google Play has its own billing rules and service fee; check Google's payments policy for your countries before assuming Stripe is fine on Android.

The 15% hurts a bit less once you remember what it buys: on a phone the purchase sheet is Face ID and done, with no card form to type into. I'd still keep the web checkout for people who find you on the web. Same price everywhere is the simplest policy; some apps charge more in the app to cover the fee, which Apple allows.

Where RevenueCat fits

The hard part of in-app purchase isn't the purchase sheet. It's knowing, in your Supabase database, who is subscribed right now, across Apple, Google and Stripe, with renewals, refunds and grace periods. You can build that yourself with App Store Server Notifications and Google's real-time developer notifications. Or you use RevenueCat, which does exactly that and has a Capacitor SDK (@revenuecat/purchases-capacitor).

Its pricing, checked today: free up to $2,500 of monthly tracked revenue, then 1% of what it tracks. For a Lovable app that's starting out, that's free for a long time, and by the time you pay $25 a month for it you're making $2,500. I'd use it. The thing I don't like is that "is this user Pro?" now lives in a third place, so we always mirror the entitlement into a Supabase column with a webhook, and the app's RLS policies read that column, not an SDK call.

How it plays out in a real project

The order we use: set up the products in App Store Connect and Google Play Console first (they need tax and banking info, and Apple reviews each new subscription with the app), add the SDK to the Capacitor project, keep the existing Stripe flow on the web, and hide the Stripe button inside the iOS app outside the US. The paywall screen in the app needs the price, the period and links to your terms and privacy policy, or review sends it back.

If a 3.1.1 rejection is what brought you here, our App Store rejection fix is $350 flat and resubmitted within 3 days. If the app isn't in the stores yet, payments are part of publishing your Lovable app to both stores.

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

Lovable on Coolify: Host It on Your Server

Aakash Verma — Fri, 23 Oct 2026 23:49:11 +0000

You can move a Lovable app onto your own server with Coolify: point Coolify at the GitHub repo Lovable syncs to, build it as a static Vite site with dist as the publish directory, add one Nginx line so page refreshes don't 404, and put your domain on it. As of October 2026 self-hosted Coolify is free, Coolify Cloud is $5 a month for up to two servers, and the server itself is the real bill (Hetzner's CAX21, 4 ARM cores and 8 GB, is €10.49 a month after their June price rise).

That moves the front end. Whether it moves the whole app depends on where your database lives, and that's the part most "self-host Lovable" threads skip.

What actually moves

A Lovable project is two things wearing one name. There's the React app Lovable writes (Vite, TypeScript, Tailwind), which compiles to a folder of static files. And there's the backend: on Lovable Cloud that's a Supabase project Lovable runs for you, with your tables, auth users, storage buckets and edge functions.

Coolify takes the first one easily. The second one stays exactly where it is unless you move it on purpose. So after a Coolify deploy you have your own server serving the pages, and the pages still talk to Lovable Cloud for every login and every query. That's a perfectly good setup if what you wanted was your own hosting, your own headers and no Lovable badge. It is not "off Lovable".

If you want the data on your side too, there are two roads. Move it to a Supabase project you own (that's the Cloud to Supabase migration we do in 1 to 2 days), or run self-hosted Supabase as a Coolify service on the same box. The second one is cheaper on paper and more work forever after: you own the backups, the Postgres upgrades and the 3 a.m. disk alert. Lovable also can't manage a self-hosted database, so new tables and policies become a developer's job instead of a chat message.

The Coolify settings that work for a Lovable repo

Coolify's own minimum is 2 CPU cores, 2 GB of RAM and 10 GB of disk, on Ubuntu, Debian or most other Linux distributions, amd64 or arm64. The install is one command on a fresh server:

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

It prints the next steps when it finishes. Then, in the dashboard:

Add a new resource from your GitHub repo (install Coolify's GitHub App so it gets push webhooks; Lovable's GitHub sync pushes to the default branch, so every Lovable edit redeploys).
Build pack Nixpacks, Site type Static, Publish directory dist.
Add your VITE_ variables if the repo doesn't already carry them in .env. In Coolify's environment variables screen, leave Build time set to Available during build, because Vite bakes these into the JavaScript at build time. A variable that's only available at runtime does nothing for a static site.
Generate the Nginx config under General and add the single-page fallback (below), then deploy.
Add your domain and let Coolify's proxy fetch the certificate.

The refresh 404 everyone hits once

Lovable apps use client-side routing. Nginx doesn't know that. Open /dashboard from the home page and it works, because React Router handled it in the browser. Hit refresh on /dashboard and Nginx looks for a file called dashboard, finds nothing and returns its plain white "404 Not Found" page.

The last founder who showed me this had already blamed Cloudflare, then the DNS, then Coolify. It's one line in the location / block:

try_files $uri $uri/ /index.html;

Coolify copies the Nginx config into the image at build time, so you have to redeploy after changing it. A restart reuses the old image and the 404 stays, which is a fun extra hour if nobody tells you.

What it costs, honestly

For the front end alone, self-hosting saves less than people expect. Static files are cheap to serve anywhere, and Lovable's own hosting is included in the plan you're probably keeping anyway, because you still build in Lovable. The money starts to matter when the backend moves too: a Lovable Cloud instance at the bigger sizes costs more per month than a whole 8 GB server running Coolify plus self-hosted Supabase.

So here's my actual opinion. If your Lovable Cloud bill is small, don't self-host for the money. Do it if you need control (headers, a region, a server you can SSH into, one bill for several apps). If the bill is large, move the backend first, because that's where the savings are, and decide about the front end after.

Not sure which camp you're in? The free Lovable cost check reads your repo and prices four ways forward, including the Coolify server route, next to what you pay now.

Things that break after the move

Auth redirect URLs are the big one. Supabase only sends magic links and OAuth callbacks to URLs on its allow list, and your new domain isn't on it until someone adds it. Do that before you switch DNS, not after the first user writes in saying the login link opens the old site.

Edge functions don't come along. They keep running where your backend runs, and the front end on Coolify calls them there, which is fine until you move the backend and forget them.

And Lovable's preview keeps working, because it never needed your server in the first place. That's handy: you keep building in Lovable, push, and Coolify ships it a minute later.

If you would rather have someone set this up with the database move done properly, that is a fixed-price job for us: your Lovable app on your own server is $500 to set up, plus the Cloud move if you need it. Or tell us about your app.

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

How to Use TestFlight for Your Lovable App

Aakash Verma — Fri, 23 Oct 2026 00:34:52 +0000

To use TestFlight with a Lovable app, wrap it with Capacitor, archive the iOS project in Xcode and upload the build to App Store Connect, then add testers on the app's TestFlight tab: up to 100 internal testers from your App Store Connect team with no review, or up to 10,000 external testers by email or public link once Apple has reviewed your first build. Each build can be tested for 90 days (Apple's TestFlight docs, checked October 20, 2026).

That's the whole mechanism. What follows is the part the docs don't tell you, which is how a web app built in Lovable behaves when real people install it from TestFlight instead of opening a preview link.

Why bother, when Lovable already has a preview

Because the preview is a website and TestFlight is the app. Everything that goes wrong on iOS goes wrong in the native shell: the keyboard covering your login button, the status bar sitting on top of your header, a deep link opening Safari instead of the app, push permission prompts that never appear. None of that shows up in the Lovable preview on your phone's browser.

TestFlight is also the dress rehearsal for App Review. The first external build goes through Apple's review against the same App Review Guidelines, so a WebView-shaped app that would get a 4.2 rejection tends to hit trouble here first, while nothing public is at stake.

Getting the build up

You need a paid Apple Developer account ($99 a year) and a Mac with Xcode. From the Capacitor project:

npm run build
npx cap sync ios
npx cap open ios

In Xcode, pick Any iOS Device (arm64) as the target, then Product → Archive. When the Organizer opens, choose Distribute App and the App Store Connect option. Xcode signs and uploads it. Expect the build to sit in "Processing" in App Store Connect for anywhere from five minutes to an hour.

Two things stop first uploads more than anything else. The build number has to go up every single time (Xcode's Build field, not the version), and the export compliance question will be waiting for you. Most Lovable apps only use standard HTTPS, which Apple treats as exempt encryption, and you can answer once in Info.plist with ITSAppUsesNonExemptEncryption set to NO so it stops asking. If your app does its own cryptography, answer honestly instead.

Internal or external: pick based on who's testing

Internal testers have to be users in your App Store Connect team with a role like Admin, Developer, App Manager or Marketing. Up to 100 of them. Builds reach them as soon as processing finishes, and you can set new builds to go to them automatically. This is for you, your cofounder and the freelancer who's fixing the safe-area padding.

External testers are everyone else, up to 10,000. You create a group, add a build, and that first build goes to App Review. Apple's page says a review is required only for the first build and later ones "may not require a full review", which in practice means most updates go out fast and now and then one sits for a day. Invite people by email, or turn on a public link and paste it wherever your users are. You can also limit the public link by device type and OS version, which is handy if you only want iPhone users on a recent iOS.

We had a founder send the public link to a 2,000-person waitlist on a Friday night. Good news: 340 installs over the weekend. Bad news: the app's sign-up email still pointed at the Lovable preview domain, so every confirmation link opened a browser tab instead of the app, and the TestFlight feedback inbox filled with screenshots of the same broken page. Test the auth emails with two people before you test with two thousand.

Reading what testers send you

Testers on current TestFlight can send feedback from inside your app by taking a screenshot, and it lands in the TestFlight Feedback section of App Store Connect with the device and OS attached. That's genuinely useful for layout bugs, because "the button is cut off" arrives with the iPhone model that cuts it off.

App Store Connect also shows sessions and crashes per build. A Capacitor app that crashes on launch usually has a missing permission string (camera, photo library, location) in Info.plist. iOS kills the app the moment it asks for that permission without one, and in TestFlight it looks like a crash with no explanation.

The 90-day thing

Every build stops working 90 days after upload, and testers see it expire. If you're using TestFlight as a slow-motion soft launch, which plenty of people do, you need to upload a fresh build before that date or your testers get locked out. Upload a new build every few weeks anyway. Testers stay in their groups across builds, so nobody needs to be re-invited.

When it's ready for the real store

Once a build has been through external testing without nasty surprises, you submit the same build for App Store review from the app's distribution page. No new upload needed. How the launch runs in both stores is on publish your Lovable app to the App Store and Google Play. If you'd rather not fight Xcode signing and the review notes yourself, we help with the submission and the reviewer's questions on every package (see the packages), or just ask us what your app needs.

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

Lovable Cloud Pricing: How to Cut the Bill

Aakash Verma — Thu, 22 Oct 2026 01:13:22 +0000

Lovable Cloud pricing has no price list of its own: your app's database, storage, traffic and backend code are paid in run credits from the same balance you build with, and top-up credits cost $0.30 each on Pro and $0.60 on Business (Lovable's docs, checked October 19, 2026). To cut the bill, open More → Cloud → Usage, see which category leads, and fix that one first. It is almost always the instance size, a scheduled job that never lets the backend sleep, or files nobody deletes.

That's the short version. The rest is how to read the page and what to change, because the fixes are not equal and some of them cost you more than they save.

Read the Usage view before you touch anything

The Usage view charts your project's run credits per day for the last 30 days (you can switch to 90) and sorts the spend into six buckets: Database (split into Database server and Database storage), AI, Compute, Network, Storage and Realtime. The number next to each bucket is credits, not dollars. Multiply by what you pay per credit if you want a dollar figure.

Two things on that page catch people. First, the total shows how much of it your monthly grant covered. Right now every Free, Pro and Business workspace gets 20 credits a month for Cloud and 4 for AI features in deployed apps. Lovable labels both "temporary, subject to change", so don't build a budget on them. Second, if the project burned more than 5 run credits in the last 7 days, owners and admins get an Optimize your usage button. It starts a chat that investigates the spend, and that chat is normal build usage, so it costs credits too.

The fixes, in the order they usually pay off

Check which instance you're really on. Lovable renamed the database sizes on July 31, 2026: the old Medium is now called Large, the old Large is X-Large, the old X-Large is 2X-Large, and a new, smaller Medium sits between Small and Large. Hourly prices didn't change, but plenty of founders who "picked Medium" in the spring are paying for what the dialog now calls Large without knowing it. Go to More → Cloud → Overview → Advanced settings, open Manage instance, and read the Estimated cost under each size. Lovable bases those estimates on your last 30 days of usage, which makes them more honest than any number I could give you here.

Don't downsize on a hunch, though. The CPU, Memory and Disk cards above it show 24 hourly segments, and a highlighted one means the database was close to its limit that hour. One red hour after a launch email is fine. A week of red afternoons means the instance is too small and shrinking it will make the app slow, which costs more in lost users than the credits you saved. A resize takes a few minutes with a short restart, so do it at night.

Find the job that keeps the lights on. Lovable pauses idle Cloud projects automatically, which is why a side project with no traffic costs close to nothing. That automatic pause does not apply to projects with scheduled jobs. We looked at a booking app last month where Compute was the top bucket every single day, including days with zero bookings. The cause was a job that ran every minute to expire unpaid reservations. Nobody had touched it since the first prompt that created it. Moved to once an hour, the daily Compute line dropped to a sliver and the app behaved exactly the same. Open Jobs in the Cloud tab and look at the schedule column before anything else.

Delete files, because paused isn't free. Stored files keep using credits even while a project is paused. If your app lets users upload photos and never cleans up abandoned drafts, Storage grows forever. A cleanup job that runs daily (yes, a job, but a cheap one) or a size limit on uploads fixes it.

Fix the slow queries. A query that scans a whole table on every page load shows up as Database server time. Ask Lovable in the chat to find the slowest queries and add indexes. This one costs build credits up front and pays back slowly, so do it after the three above.

Pick a cheaper model for AI features. The AI bucket is charged per call by model and tokens. A support bot that sends the whole chat history with every message on the biggest model is the classic one. A smaller model for the first answer and shorter context usually halves it.

The top-up price trap on Business

This one is just arithmetic. A one-time top-up is $15 for 50 credits on Pro and $30 for 50 credits on Business, so a Business workspace pays twice as much for every extra credit its live app burns. If you upgraded to Business for SSO or team features and your app's Cloud usage runs past the plan's credits every month, compare that against a bigger Pro plan before the next renewal.

Whatever plan you're on, set a monthly spend limit on auto top-up (Workspace settings → Plans & credit usage → Add credits → Auto top-up). Without one, a bot hammering your signup form can top you up all weekend. With one, the worst case is the backend pausing until you add credits, and your published site stays up while that happens.

When trimming isn't the answer

Some apps are simply busy, and that's the good problem. Once the Usage view shows Database server and Network as the two biggest lines on normal traffic, you're paying Lovable's markup on infrastructure you could run on your own Supabase project, with a bill in dollars you can read line by line. Our free Lovable cost check scans your repo and shows what the same app would cost on its own backend, and moving from Lovable Cloud to Supabase takes us one to two days with your data and users included. Prices are on the pricing page.

If you'd rather someone else read the Usage page with you, send us a note with a screenshot of it.

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

What It Costs to Turn Lovable Into an App

Aakash Verma — Tue, 20 Oct 2026 23:54:40 +0000

Turning a Lovable app into an iPhone and Android app costs $124 in store fees in the first year ($99 a year for Apple's Developer Program, $25 once for Google Play) plus the build itself, which with us is a fixed $300, $600 or $1,000 depending on how many screens the app has. So a typical 10-screen Lovable app lands at about $724 for year one, and $99 a year after that, before the stores take their cut of any sales.

People searching "how much does it cost to make an app" get quotes from $5,000 to $150,000, and those numbers are real for apps built from nothing. Your situation is different. The screens, the logic and the Supabase backend already exist in your Lovable project, and most of the cost of an app is building those.

The fees you can't avoid

Apple: $99 a year. That's the Apple Developer Program. You need it for TestFlight and the App Store, and it renews every year. If the app stops being paid for, it disappears from the store. Enrolling as a company instead of a person also needs a D-U-N-S number. The number is free, but getting one can take a week or more, and nobody warns you about that until you're stuck on the form.

Google: $25, once. The Google Play Console registration fee is a one-time US$25. The catch is time, not money: a new personal developer account has to run a closed test with at least 12 testers for 14 days before Google lets the app go to production. Line up those 12 people early. Your friends will forget to open the test link.

The cut, if you sell anything. Both stores take 15% of digital sales for developers under $1 million a year (Apple's Small Business Program has to be joined, it isn't automatic). If your Lovable app sells a subscription through Stripe, the native version may have to sell it through in-app purchase instead, and that changes your margins and some of your code. Physical goods and services, like bookings or deliveries, can keep Stripe.

The build: where the real money goes

There are two ways to do it, and the price difference between them is smaller than people expect.

Capacitor, from the same code. Your Lovable project becomes the app. We add the native pieces Apple wants to see before it approves anything (push notifications, a proper splash screen, offline handling, the share sheet), build it for both stores, and submit it. You keep building in Lovable, and every change ships to the web and to the apps. This is the default for most founders because it doesn't fork the codebase. You can compare it with React Native here.

A native rebuild in React Native or Flutter. Same Supabase backend, new front end. It makes sense for apps people live in all day: a feed, chat, maps, video. It's more work for us, but we price both paths the same, so pick the one that suits the app.

Our packages, for either path: $300 up to 5 screens, $600 up to 15, $1,000 for 25 and more. Count your screens honestly. A settings page with three tabs is three screens. The full breakdown is on the home page.

If you'd rather do it yourself, the build costs you nothing but time. Capacitor is free, and you can build Android on any laptop. For iOS you need a Mac with Xcode, and a few evenings to get through signing certificates, provisioning profiles and App Store Connect. One founder told us they spent a full weekend on the "No signing certificate found" error alone, and then the first submission came back under guideline 4.2 because the app was a plain wrapper. That rejection is the common one, and it's fixable.

What it costs after launch

Less than you'd think, but not zero.

Push notifications through Firebase Cloud Messaging are free. Your Supabase or Lovable Cloud bill doesn't change much because app users hit the same backend as web users. What does cost money is keeping up with the platforms. Apple and Google raise their minimum SDK targets every year, Capacitor ships a major version roughly yearly (Capacitor 8 came out this year), and an app that isn't updated for a year or two gets flagged or pulled. Budget a small update once or twice a year. For most apps that's a day of work, not a rebuild.

The other running cost is review time. Every update goes through Apple's review again, usually in a day, occasionally with a rejection over a screenshot or a missing account-deletion button. That costs time rather than money, but it's real.

The honest total

	Year one	Every year after
Store fees	$124	$99
Build with us (10 screens, $600 package)	$600	-
Platform updates	a day of work, if a new OS lands	a day of work, once or twice
Store cut on digital sales	15% under $1M	15% under $1M

Around $724 to get a 10-screen Lovable app onto both stores, versus five figures for an app built from scratch. The difference is the work you already did in Lovable.

Want a fixed quote for yours? Tell us about the app and how many screens it has.

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