Lovable, the app builder at lovable.dev, gets most owners to a working demo. This page picks up at the moment the building stops. The screens are done, the demo works, and the next piece of work is the one you cannot do yourself. Somebody is going to want paying for it.
One owner described that moment in public without asking a single question about money. In a public Reddit post they wrote: “Hi everyone, I’ve built my entire ERP system in Lovable , and now I’m planning the production infrastructure. I’m confused about where I should store my application data.”
That is the buyer this page is written for, one step before they become one. There is no price in that post, and there is no price waiting for them on the other side of it either. What there is, on the eight seller pages read for this article, is a lot of time and terms and very little money.
The figure turns on which gates the app has not passed, not on how big it looks. Of eight sellers of this work read on 31 August 2026, four attach a currency figure to their own work and four attach none, and the unit most of them publish is time.
What follows was assembled by reading Lovable’s own payments documentation on 31 August 2026 and, on the same day, the pages eight sellers of Lovable work publish about their own prices, then writing down for each seller both the figure it states and the figure it does not. No Lovable account was used, no seller was asked for a price, and nothing here comes from running the product.
How much does it cost to hire a developer for a Lovable app?
No published number answers it, and that is structural. Four of the eight sellers read for this page attach a currency figure to their own work, and only two of those figures cover a piece of work as a whole. What moves the bill is which gates the app has still to pass, with payments below as the worked example.
The structural part matters more than it sounds. A Lovable app that looks finished is a set of screens plus whatever the builder wired underneath them while it was generating those screens. Two apps with the same number of screens can be one afternoon apart or six weeks apart, depending on which of the requirements in the next section they already satisfy and which they do not. A seller who quotes you before looking is guessing at that gap. A seller who refuses to quote before looking is telling you the gap exists.
So the honest answer splits into two questions, and both of them are answerable before anybody quotes.
The first is which gates are unpassed. That is a readable list, published by the builder, and the whole of the next section is that list.
The second is how you are buying: an hour of somebody’s time, or one agreed outcome. Buying somebody’s time by the hour and buying one agreed outcome are two different purchases, and the argument between them is not specific to this builder. The sellers below are split on it, and the split is visible in what each of them chooses to publish.
Choosing the person is a separate decision from pricing the work, and it turns on how much of this builder’s own machinery a candidate can already name. The version of this question with no builder named, what any existing app costs to have worked on, is answered on the hiring-cost page.
What a Lovable app still has to pass before it takes money
Payments are the worked example on this page, because it is the addition most people ask for next and the one the builder documents gate by gate; the same reading applies to any other unfinished piece, and the access and assessment questions further down apply whatever the piece is. Lovable’s payments documentation, read on 31 August 2026, sets out what has to be true before that can happen. The table below is that list, with the last column added by this page.
| Gate | What the documentation requires | Who can clear it | Effect on the bill |
|---|---|---|---|
| A paid plan | ”built-in payments require a paid Lovable plan” | The account holder | None. It is a subscription, not work |
| The built-in backend | Payments “aren’t available for projects connected to your own Supabase project” | Nobody, while the project is on its own database | The largest swing on this page |
| Admin rights | ”only project admins and owners, and workspace admins and owners, can set up payments” | You, before anyone starts | Access delay, not work |
| Three policy pages | A privacy policy, terms of service and refund policy must exist | You, or somebody who writes | Small, often already done |
| Provider verification | Paddle screens the seller; Stripe needs the account claimed and onboarding finished | You, with business details | Waiting, not developer time |
| One provider only | ”you cannot run Paddle and Stripe in the same project” | Decided once, up front | Cheap now, expensive later |
| One subscription per user | Each user has one active subscription per environment by default | A developer, if you sell more | Real work if the product needs it |
| No forking afterwards | ”once payments are enabled, the project cannot be forked” | Nobody | Removes the cheap way to try a change |
Two more facts from the same page do not fit a row but change what a developer can safely touch. Lovable registers its webhook endpoints automatically and the documentation says they must stay in place, so creating or deleting webhooks by hand is off the table. And physical goods are not this integration’s job at all: the documentation points at the Shopify integration for those.
The plan requirement is the only one on that list that is purely a subscription. What the builder charges you directly, in plan fees and credits, is kept current on the credit page, and no figure of it is repeated on this one.
Read the table as a bill and a pattern appears. Three of the eight gates cost nothing but your own attention. Two are waiting. One is a decision. One is genuine development work only if your product needs it. And one, the second row, can turn the whole request into a different job.
The gate that turns a small job into a build
The second row is worth its own section because it is the commonest reason a request a founder thinks is small comes back large.
Lovable’s payments documentation ties the built-in payments feature to the built-in backend, which is where it keeps webhook endpoints and subscription state, and rules the feature out for a project pointed at a Supabase project of your own. The page makes the same point again for the external-database case in equally plain terms: the feature needs that backend today, and a project wired straight to Supabase is not covered yet.
Now put that next to the advice a founder is most likely to have already followed. Moving a project onto its own database is the sensible, frequently recommended step for anybody who wants their data somewhere they control. Plenty of owners do it early, before payments are anywhere near the plan. The consequence only shows up later, on the day somebody asks for a checkout.
At that point “just add payments” stops being a switch. The work becomes a payment integration built by hand against a provider, plus the webhook handling, plus the subscription state, plus the environment separation, all of which the built-in path would otherwise have covered. That is a build. It is priced like a build, and no seller on the list below prices it in advance.
This is also the single sharpest question to put to anyone quoting you: ask them whether the project is on the built-in backend or on its own database, and watch whether they already know the difference it makes. What the built-in backend quietly does, and what stops happening when a project leaves it, is described where that move is documented.
The reverse case has a price of its own and is not this page’s subject. Leaving the builder is priced as its own job with its own sellers, and nothing on this page is a price for that move.
An app already moved to its own database cannot use the built-in payments path, so a request that sounds like a switch is a build, and it arrives with a build’s price.
What sellers who work on Lovable apps actually publish
Eight pages that sell work on Lovable apps were read on 31 August 2026. The point of reading all eight on one day was to find out what the market’s published unit for this job actually is. It is time.
| Seller | What its page publishes | What it does not publish |
|---|---|---|
| RapidDev | A flat fee for its paid review, plus a free first one | A price for finishing an app |
| AppStuck | An hourly price, a job size in hours, two turnarounds | A price for the whole job |
| Fora Soft | Three tiers, each a “from” figure with a week count | Any figure that is not a starting one |
| Pragmatic Coders | A free consultation and an assessment priced from zero | A figure for the work after it |
| Hephon | Payment terms, durations, a post-launch fix window | Any currency figure |
| Concetto Labs | A hiring page and a general remark about rates | A rate of its own |
| Goodspeed | A build timeline in weeks | Any price for its own work |
| Fingent | Three ways to buy the work | Any currency figure |
The figures behind those cells, with the label each page gives them.
RapidDev’s Lovable developers page states “that’s a flat $1,000” for what it calls its “full security and architecture audit”, and separately that “The initial review is free.” The same page carries a second sentence with the same number attached to something else entirely: “Small fixes and integrations can start around $1,000.” One figure, two jobs, and the page says the exact number for anything larger follows once they understand what you need. Read 31 August 2026.
Pragmatic Coders’ vibe coding rescue page prices its code assessment “From $0*”, with the asterisk reading “Depending on codebase size”, and states that the first consultation is “FREE”. As of 31 August 2026, that page does not render a figure for the rescue work that follows the assessment to an automated read. The figure that renders is for the step before the work, not the work.
AppStuck and Fora Soft both publish figures, and both of those figures are already held elsewhere on this site. Published prices for repairing one broken behaviour on this builder are held on the page that prices those repairs, and none of them is restated here. What those two pages publish that appears nowhere else is time. AppStuck’s Lovable page gives a typical job size of five to forty hours depending on complexity; states “Within 48 hours of starting, you get a written plan”; and puts a production launch, for an app that is seventy to eighty percent done, at two to four weeks. Fora Soft’s Lovable page states the boundary its tiers sit inside: “Pricing is always project-specific and based on your exact requirements.” Both read 31 August 2026.
Hephon’s page publishes no money at all and a great deal of process. It promises a written assessment within 48 hours of access and “one fixed price to finish and harden it”, states that “Most rescues take two to four weeks”, that payment runs “30% on signature, the rest on milestones”, and that “Every rescue includes 30 days of fixes.” The thirty percent is a payment term rather than a price, and the page never says thirty percent of what. As of 31 August 2026, Hephon’s Lovable page does not render a figure to an automated read.
Goodspeed publishes a timeline rather than a price: eight to twelve weeks from idea to live product. As of 31 August 2026, Goodspeed’s site does not render a price for its own work to an automated read, and the currency figures it does carry are client outcomes rather than prices.
Fingent publishes the shapes work can be bought in rather than what any of them costs. Its Lovable developers page states “You can hire us for one-time support, short-term projects, or ongoing partnerships, whatever works best for you”, and describes reviewing existing code and building on top of it. As of 31 August 2026, Fingent’s Lovable page does not render a figure to an automated read.
Concetto Labs is the one whose absence is worth naming precisely, because its page sounds like it publishes a rate and does not. It advertises transparent pricing and a flexible hourly rate as a benefit, and the only numbers anywhere near it sit in a general remark about what rates run to depending on where somebody lives and how good they are. That remark is about the market, not about the company. As of 31 August 2026, Concetto Labs’ Lovable hiring page does not render a rate of its own to an automated read.
So the count, on that one day: four of the eight attach a currency figure to their own work and four attach none. Of the four that do, two put a figure on a named piece of work as a whole, one prices an hour of time, and one prices only the assessment that comes before the work. Not one of the eight publishes a price for finishing a Lovable app.
The eight addresses that follow are printed plain rather than hyperlinked, because every company in this section is selling the reader the same work. The pages read were rapidevelopers.com/lovable-ai-developers, appstuck.com/platforms/lovable, forasoft.com/lovable-app-bug-fixing, pragmaticcoders.com/services/vibe-coding-rescue, hephon.ai/vibe-coding-rescue/lovable/hire-a-developer, concettolabs.com/hire-lovable-ai-developer, goodspeed.studio and fingent.com/lovable-developers.
Why a finished screen tells you nothing about the bill
Two sellers can look at the same app and come back an order of magnitude apart. Both can be honest. The difference is what each of them looked at.
A screen is evidence that a screen exists, and evidence of nothing behind it. In a fixed study of 26 real AI-built applications audited across June and July 2026 in three cohorts, with the pattern work drawn from the 21 third-party apps in the findings ledger, one recurring shape is controls that exist in the code and are never connected to anything: a rate limiter no request path ever calls, a failure boundary the app never installs, a written safety policy that only a person ever reads. The index recording that pattern names apps by anonymised label rather than counting them, so there is no percentage to quote here and this page does not invent one.
What it does support is one argument. A price quoted from screens and a price quoted from the code are different numbers, because the person reading the code can see which of those controls is wired and which is decoration. The seller who quotes from the demo is pricing what you showed them. The seller who insists on the repository first is pricing what is there.
That is why free assessments keep appearing in the section above. Generosity has very little to do with it. A seller who reads the code first is refusing to price the gap between the screens and the code without measuring it, which is the same instinct that left four of the eight publishing no figure at all.
Buying a read of the code and nothing else is its own purchase, and what that market charges has its own page. A sustained cleanup is counted before anybody prices it, and that market is held on its own page.
Two adjacent counts sit next to this one without being it. What one broken thing costs to have repaired, on any builder at all, is counted separately from the list of pieces priced here. And what clearing the last launch blockers costs when the app was not made on this particular builder is a wider count with its own published sources.
The parts of this you can settle before money changes hands
Several things on the gate list cost nothing but an hour of your own attention, and doing them first makes every quote you receive cheaper and more accurate at the same time.
Find out which backend the project is on. That single fact decides whether the payments request is a switch or a build, and you can establish it yourself in the project settings before you talk to anybody.
Write the three policy pages, or have them written. The documentation requires a privacy policy, terms of service and a refund policy to exist before payments go live. None of that is developer work, and a developer billing you to wait for it is billing you to wait.
Start the provider verification early. Paddle screens the seller with its own checks and Stripe wants the account claimed and onboarding finished. Both are your business details rather than anybody’s code, and both take calendar time that runs in parallel with everything else if you start it now.
Decide the provider. Paddle and Stripe cannot run in the same project, so this is a decision made once, and it is much cheaper to make it before the integration exists than after.
Run the checks that do not need a developer. The behavioural checks an owner can run without paying anybody are written out on the readiness page; this page begins where those checks have already failed.
And take the free assessments the sellers publish, which several of them do. RapidDev states its initial review is free. Pragmatic Coders states its first consultation is free and prices its code assessment “From $0*”. Hephon promises a written assessment within 48 hours of access, and AppStuck promises a written plan within 48 hours of starting; neither page says whether that reading is free, so ask before you grant access. Two readings stated as free, and up to four if the other two turn out to be, is two to four opinions on where the gap actually is, and the disagreements between them are the most useful thing you will get out of the exercise.
One caution on the free reading, and it is arithmetic rather than cynicism. A free assessment is a sales step, and the seller writing it has an interest in what it concludes. That is fine as long as you have more than one of them, which is exactly why taking all four beats taking the best-reviewed one.
Where AxonBuild comes into this
AxonBuild works on apps people have already built with Lovable and similar tools: fixing what keeps breaking and adding what customers have asked for.
The way in is a free 20-minute video call. You show Bilal the app, explain what should work and what happens instead, and say what you have tried. He talks through what needs checking, and if the cause is not clear on screen, he explains which part of the code he needs to check afterward. If you want him to make the change, he checks the app and gives you a fixed quote, you agree what the app should do, and you pay after you see it working. The call produces no written thing of any kind.
Where that lands on this page’s subject is specific. Clearing one gate in a working Lovable app and finishing the whole app are quoted the same way, after the code has been checked, rather than priced from a table. You can keep building in Lovable while that work happens; Bilal works in the same code alongside it.
Paying somebody to keep it alive after this job ends is a recurring arrangement, priced by the month rather than by the piece, and it is a different purchase from the one this page describes. Whether the builder earns its place before any of this arises is a separate judgement, made against what it does well rather than against what finishing costs.
Not one of the eight sellers read on 31 August 2026 publishes a price for finishing a Lovable app. Four attach no price to their own work at all.
Common questions about paying somebody to work on a Lovable app
Why do two quotes for the same Lovable app differ so much?
Because the two people quoting looked at different things. A quote made from the screens prices what the demo shows; a quote made from the repository prices what is actually wired underneath it, and on an AI-built app those two pictures can be far apart. The gates in Lovable’s payments documentation are the concrete version of that gap: a project on the built-in backend and a project on its own database look identical in the browser and are weeks apart in the work.
Is switching on payments a small job or a big one?
It depends entirely on one fact, and you can check it yourself today. Lovable’s payments documentation, read on 31 August 2026, closes the built-in payments path to any project that has been wired to its own Supabase database. If the project is still on the built-in backend, turning payments on is mostly configuration plus your own policy pages and provider verification. If it has already been moved to its own database, the built-in path is closed and the payment integration has to be built.
What happens to the price if the backend was already moved to my own database?
The request changes shape rather than getting a surcharge. Instead of enabling a built-in integration, somebody has to build the checkout, the webhook handling and the subscription state against a payment provider directly, and then keep them correct across environments. None of the eight sellers read on 31 August 2026 publishes a figure for that, which is itself the answer: it is quoted after somebody has looked, not before.
Do I have to pay somebody before I know what is wrong?
No, and several sellers publish exactly that. RapidDev states its initial review is free, Pragmatic Coders states its first consultation is free and prices its code assessment “From $0*” with the asterisk reading “Depending on codebase size”, Hephon promises a written assessment within 48 hours of access, and AppStuck promises a written plan within 48 hours of starting, though those last two pages do not say whether the reading is free. All four read 31 August 2026. Taking more than one of the free ones costs nothing and gives you disagreements to read.
Can I buy just the piece that is blocking launch?
Sometimes, and it is worth asking for explicitly. The gates in the payments documentation are separable: policy pages, provider verification, admin permissions and the provider decision can each be cleared on their own, and none of them requires the whole app to be finished first. The one that resists being bought as a piece is the backend requirement, because it is not a piece at all but a fork in the road.
Why do so many sellers publish hours instead of a price?
Because hours are the only unit they can state truthfully without seeing the code. Of the eight pages read on 31 August 2026, the published units include a job size in hours, a written plan within 48 hours, two to four weeks to a production launch, eight to twelve weeks from idea to live product, thirty percent on signature with the rest on milestones, and thirty days of fixes after launch. Every one of those is time or terms. A seller publishing a price for finishing an app would be pricing a gap they have not measured.
Is a free assessment worth taking?
Yes, with one adjustment: take more than one. A free assessment is a sales step written by somebody who would like the job, so a single one tells you as much about the seller as about the app. Two or three of them, read side by side, show you where they agree about what is missing, and the agreements are the reliable part. Four of the sellers read for this page publish some form of free first look.
What does AxonBuild charge to work on a Lovable app?
There is no published rate. The 20-minute video call is free. If you want a change made, whether that is one gate or the whole finish, Bilal checks the app first and gives you a fixed quote, and you pay after you see the work running.
Built it with AI. Can’t get the last part right?
That’s the normal state of an AI-built app, and it’s fixable. I trace what the app actually does, explain what needs changing, and build it if you want me to.
Talk about your app → 
Free 20-minute video call with Bilal.