Cost to build an app with AI, and what Lovable won't do
The cost to build an app with AI has two very different answers. With Lovable you pay a subscription plus the credits you use, and within days you have screens that work. Having Nimboo build it starts at €3,500 for the design and €36,000 for an MVP in production, which pays for the engineering the generator doesn’t do.
The short answer
Each route delivers something different.
| Route | What you have at the end | What it costs |
|---|---|---|
| You build it in Lovable | Screens that work within days. Security and permissions are your responsibility, according to Lovable’s documentation | Subscription and credits. On the Pro plan, 50 extra credits cost $15, and hosting on Lovable Cloud draws from the same balance |
| You commission the design | Domain and data model, use cases, architecture, a clickable prototype of the flows and a firm quote for the MVP | From €3,500 at Nimboo. Deducted from the MVP if you go ahead within 60 days |
| You commission an MVP in production | Two flows end to end and two roles with real users, each organization’s data kept apart, an admin panel and backups that have actually been restored | From €36,000 at Nimboo, design included |
Almost all of the gap between the first row and the third comes from work that never appears on screen. Exactly what each tier includes is listed on the pricing page.
What Lovable does well
Lovable is good at what you can see. You describe a screen in a message, Lovable generates it, and in an afternoon you have something to show the people who would have to buy it, without writing a line of code.
It doesn’t lock you in either. According to its documentation, Lovable syncs the code with a GitHub repository in both directions, so you can deploy it somewhere else.
Before publishing, it runs a scan. Lovable itself explains that the scan catches common issues but can’t guarantee complete security. It states in writing that making sure the app meets its security requirements is the builder’s responsibility, and for sensitive data it recommends an additional professional security review.
The engineering behind the price
What you pay for when you commission an app is the work that decides whether it holds up with real customers: the business model, the architecture, the tests that protect every change and the way it withstands failures. Almost all of it happens before the first screen is final.
The domain model and the use cases
It starts with the domain. The domain model is a drawing of the business before any code: the pieces that make it up and the rules that decide who can touch each one. For a product used by several companies at once, it comes out looking a lot like this.
Six pieces and how they relate. Every line is a business rule, and it gets agreed before any code is written.
Every line is a decision. Whether a user belongs to one organization or several looks like a minor detail, but it changes the filter on every query in the product, from the first to the last. Nimboo agrees on the model with you before writing any code.
Moving it later means a rewrite.
On top of that model come the use cases, which describe each thing someone does with the product, step by step, along with what has to be checked at each step. A sequence diagram shows who talks to whom and in what order. Here’s what inviting a teammate looks like.
Inviting a teammate, step by step. The role is checked on the server, and the email goes out through a queue so nobody waits for it to send.
The second step doesn’t exist in a demo. The server checks the permission, because hiding the button on screen doesn’t stop anyone from skipping the screen and sending the same request straight to the server. And the email goes out through a queue: if the provider is slow, the person sending the invitation isn’t left waiting in front of the screen.
The architecture, with the business at the center
The architecture decides where each piece lives. Nimboo uses hexagonal architecture, also called ports and adapters, which puts the business rules at the center without them knowing which database or payment provider sits outside.
Business rules at the center and everything outside plugged into a port. Changing payment provider means changing one adapter, and the domain never notices.
Every connection to the outside world is an adapter plugged into a port. If tomorrow you swap Stripe for another payment provider, or move invoicing to QuickBooks, all it takes is a new adapter and the business rules stay untouched. The tests exercise the entire core without connecting it to anything.
Tests that stop a change from breaking what came before
Any change can break something else. That’s a regression: something that worked stops working because of a change made somewhere else, and if nothing checks the whole product after every change, it’s a user who finds it.
In Nimboo’s products, every change passes automated tests before it’s deployed. Unit tests check the rules one by one. Integration tests check the pieces together. If any of them fails, the change doesn’t ship. Changing the data structure while customers are using it has its own procedure, explained step by step in zero-downtime database migrations.
Resilience: what happens when something fails
Resilience means the product stays up when something outside fails, or when ten times the usual work arrives all at once.
Heavy work, like generating invoices or sending a thousand emails, goes into a queue shared by several workers, and if one goes down, the others carry on and redo whatever was left half-done. If usage goes up, more machines come in. If it drops, they shut down, and the bill drops with them. A retried payment can’t charge the card twice, and the fix has a name: idempotency. A slow provider can’t bring the whole product down either; that’s what circuit breakers and bulkheads are for.
Before handover, Nimboo actually restores a full backup and sets up alerts so they reach a specific person’s phone the moment something fails.
What the price of building it with AI leaves out
The permissions review is missing. Lovable’s price doesn’t include anyone checking who can read each piece of data, and that’s where the public failures of apps generated with the tool come from.
In 2025, researcher Matt Palmer looked at 1,645 apps published with Lovable and found 170, about 10.3%, that let anyone read their users’ data. The cause was database access rules that were missing or misconfigured. The flaw has its own vulnerability record, CVE-2025-48757, which Lovable disputes on the grounds that each customer is responsible for their own app’s security.
In February 2026, The Register reported on a single Lovable-hosted app with 18,697 user records exposed and 16 vulnerabilities, 6 of them critical. The access control was inverted: it blocked the people it should have let in and let in the people it should have blocked. Lovable replied that its scan had flagged problems and that acting on its recommendations was up to the person who built and published the app. It added that the project included code Lovable hadn’t generated, and that the vulnerable database wasn’t hosted by Lovable.
Neither case is a comparison with hand-written apps. They show where things fail, and where they fail is permissions, when nobody designed them before building the app.
What the second year costs
An app built in Lovable keeps spending credits in its second year, because every change you ask for is a message, and according to its documentation a message in Build mode uses between 0.50 and 2 credits in the examples it publishes. Hosting on Lovable Cloud comes out of the same balance.
A commissioned app needs someone keeping an eye on it. At Nimboo, maintenance runs from €390 to €1,600 a month: the first tier covers monitoring, security patches and a response within 48 business hours, and the top tier adds 10 hours a month of improvements and a 4-hour response. The other recurring costs are in what custom SaaS development costs.
When commissioning it isn’t worth it
If you haven’t yet shown the idea to anyone who would pay for it, don’t commission an MVP from anyone, Nimboo included, because you don’t know yet what needs building. Build it in Lovable and show it around.
A generator is more than enough to find out whether an idea gets any interest. There’s no fixed date for moving on from it. The moment comes when the app is going to store real customers’ data or charge people to use it, because from that day on, a permissions flaw exposes the data of someone who trusted you.
If you’ve already built it and it’s starting to break, the prototype diagnosis tells you in a week what holds up and what doesn’t. Nimboo keeps what your users have already validated and replaces the generated code.
How to compare two quotes
Compare answers before figures. These six questions separate vendors who build with a method from those who hand over whatever the generator produced, and a serious vendor answers them without having to think twice:
- Who draws the domain model, and do they show it to you before writing code?
- Do they hand over the architecture documentation? At Nimboo it’s part of the delivery, along with the deployment documentation, written so that an outsider who has never seen the project can follow it.
- What tests does every change pass before it’s deployed, and what happens if one fails?
- Where does the product check permissions? The only good answer is the server.
- What happens to the product if an outside provider, like the payment provider or email, goes down on your busiest day?
- Who owns the code and the infrastructure? At Nimboo, the repository and infrastructure are in your name from day one, and the code becomes yours with the final payment for the project.
All of this work pays off the day someone other than you trusts the app with their data. Not a day before.
What each price includes. Product design and the MVP are broken down on the pricing page. If you have an idea and want to know what it would cost to build it this way, the product design phase of custom SaaS puts a firm price on it before any production code is written.