Nobody can give a real price to finish a Lovable, Bolt or Cursor app before they have looked at the code. The cost depends mostly on how much of the foundation has to be rebuilt: the database, the logins and the way the app stores data. A serious team starts with a fixed-price audit, then quotes from what it finds.
You built an app with Lovable, Bolt or Cursor. It works when you click through it. Now you want real customers to use it, and you want to know one thing: how much will it cost to get there? The honest answer is that nobody can give you a real number before they have looked at the code. But you can understand what you pay for, what moves the price, and how to spend your budget well. This guide explains all of it in plain words.
Why nobody should quote before seeing the code
Two apps can look the same on screen and be very different underneath. One may have a clean database and safe logins. The other may show every user's data to anyone who knows where to look. From the outside, you cannot tell which one you have, and often the AI tool cannot tell you either.
That is why a serious team starts with an audit: a fixed-scope review of your app, done before anyone quotes the build. If someone gives you a firm price after a quick look at your demo, they are guessing. The guess can be too low (and grow later) or too high (and you pay for work you did not need).
What you pay for: the last 20%
AI tools get an app to about 80% very fast. The last 20% is most of the real engineering, and it is the part you cannot see in a demo. When you pay to finish an AI-built app, this is usually what you pay for:
- Security. Checking that each user sees only their own data, that secret keys (the passwords your app uses to talk to other services) are not visible in the browser, and that the database is not open to everyone.
- Accounts. Sign-up, login, password reset and email checks that work every time, not only when everything goes right.
- Payments. Taking a card is the easy part. Failed charges, refunds, subscriptions that end and the emails for each case are the real work.
- Errors. What the app does when something goes wrong, and a way for you to know about it before a customer writes in.
- Data that can grow. A database structure that works for ten users and still works for ten thousand.
- Real devices. Testing on real phones, older browsers and slow connections, not just a laptop.
- Launch basics. Your domain, hosting in your name, analytics, emails and error monitoring. For a mobile app, publishing to the App Store and Google Play, which each review your app before it goes live.
What makes the price go up or down
The biggest factor is simple: how much of the foundation has to be rebuilt. The foundation is the part under the screens: the database, the logins, and the way the app stores and moves data. A few other things matter too:
- How many core flows. A flow is one complete task, for example sign up, book and pay. One flow costs less than five flows that depend on each other.
- Outside services. Each connection to another service (payments, maps, email, AI) adds work and testing.
- Web or mobile. A web app is the fastest start. Adding iOS and Android apps adds time.
- How tangled the code is. If the AI rewrote the same parts many times, the code is harder to read and slower to fix.
- Who holds the accounts. If a previous developer still holds your code or hosting, getting it back into your name comes first.
The three outcomes, and what each means for your budget
An audit usually points to one of three outcomes. Each has a very different cost:
- Rescue. The foundation is sound and the work is truly most of the way there. We finish the app, make it secure and stable, and launch it. This is the most common case and the least expensive. For a tidy prototype that needs hardening, real accounts and payments, it is usually a matter of weeks.
- Rebuild the foundation. The screens and the idea are worth keeping, but the plumbing underneath is not. We keep what is good and redo the rest. It costs more than a rescue, but it is often faster than trying to untangle the old code.
- Restart. Sometimes a clean build is the fastest route. Your prototype then becomes the brief: the clearest description of what you want. The cost is then close to a new MVP, and our guide to what an MVP costs in 2026 gives the market ranges for that.
A demo proves your idea once. A finished app has to work every time, for every user. That difference is what you pay for.
What the audit costs, and what you get
At Swipe Up, the audit is a fixed price, agreed before we start. We run your app outside the tool that generated it, read the code and test it. You get a clear report, one honest recommendation, and a fixed scope and timeline to launch. The report is yours whatever you decide next, so you can use it with us or with another developer.
Finishing or rebuilding is then quoted from what the audit finds, never blind. This protects you in both directions: you do not pay for work you do not need, and the price does not grow halfway through because of a problem nobody looked for. You can see each step on our page about finishing your AI-built app if you want the details.
Costs people forget
- Running costs. Hosting, the database and outside services cost a little each month. Small at first, but not zero.
- Store fees. Apple and Google each charge a developer account fee to publish apps in their stores.
- Changes after launch. Your first users will ask for changes. Keep some budget for them.
- Care. Software needs updates and security fixes. A care plan keeps your app updated, monitored and secure after launch.
How to spend less
- Stop adding features now. Each new feature on a weak base makes the cleanup bigger.
- Own your accounts. The code, the domain, the hosting and the keys should all be in your name.
- Keep the prototype. Even if parts are rebuilt, it is the best brief you will ever write.
- Launch with less. Launch with the one flow that matters most. The rest can wait for version two.
- Be careful with a price given without an audit. A low guess can grow, and a high guess can hide work you do not need.
The bottom line
Finishing an AI-built app is usually faster and cheaper than starting from a blank page, because the idea is proven and part of the work can be kept. How much it costs depends on what is under the screens, not on how the demo looks. If you want to understand why these builds get stuck in the first place, read from AI prototype to real product before you decide. And if your app is ready for a proper look, start with an audit and you will know exactly where you stand.
