How to turn an AI-built prototype from Lovable, Bolt or Cursor into a real app
A prototype built with Lovable, Bolt, Cursor or a similar AI tool is a good start: it proves the screens and the flow you want. To become a real product it usually needs a review of data security, payments, error handling and store requirements, and for the App Store it needs native features, not only a website in a shell. Some prototypes can be finished; others are faster to rebuild using the prototype as the spec. A developer can tell you which in a short code review.
What an AI-built prototype is good at
- Showing the idea. You can click through it. That beats any written brief.
- Fixing the scope. It forces decisions about screens, fields and flows.
- Testing demand. You can put it in front of real users before paying for a full build.
Many developers treat a vibe-coded app as an interactive spec rather than a finished codebase. That is not an insult: a clear spec is one of the most valuable things you can hand a developer. See how to write an app brief.
What usually needs work
These are the areas a developer checks first. Not every prototype has every problem.
| Area | Typical issue in a prototype | What "real" looks like |
|---|---|---|
| Data access | Database rules left open, so one user can read another's data (for example Supabase row level security not enabled) | Every table has access rules, tested with two accounts |
| Secrets | API keys in front-end code | Keys on the server, rotated if they were exposed |
| Auth | Sign-up works, but reset, email change and deletion do not | Full account lifecycle, including in-app account deletion |
| Payments | A checkout button with no webhook handling | Access granted and removed based on payment status |
| Errors | Blank screens when something fails | Error states, retries, error tracking |
| Structure | One huge file, duplicated logic | Code another developer can change safely |
| Tests and builds | None | A repeatable build and basic tests on the core flow |
| Privacy | No policy, unknown SDK data collection | Privacy policy, store privacy forms filled in accurately |
Finish it or rebuild it?
A developer can usually decide after reading the code and running it.
Finish it when:
- the stack is mainstream (React, TypeScript, a standard database),
- the data model makes sense,
- problems are local: missing rules, missing states, a few bad files.
Rebuild, using the prototype as the spec, when:
- the data model is wrong for the product,
- every screen has its own copy of the logic,
- you need a native mobile app and the prototype is a web app built only for desktop.
Rebuild does not mean starting from zero. The screens, copy, flows and decisions in the prototype carry over. Ask for a written recommendation with reasons, not a gut call.
Getting a web prototype into the App Store
Most AI app builders produce web apps. You have three routes to the stores:
- Wrap it. Put the web app inside a native shell with Capacitor, a native runtime for web apps (Capacitor docs), or a React Native webview. This is fastest, but Apple's guideline 4.2 rejects apps that do not offer more than a website, and Apple lists web clippings and link collections among common rejection reasons (Apple, App Review). A wrapped app needs real native value: in-app purchase, notifications, widgets, offline use, Home Screen shortcuts.
- Rebuild the UI natively in React Native with Expo or in SwiftUI, reusing the backend and logic. More work, better result on phones. See native vs React Native vs Flutter.
- Stay on the web as a progressive web app if you do not need store distribution yet.
Whichever route, the store rules apply: digital purchases inside the app go through Apple's in-app purchase (guideline 3.1.1), apps with accounts must offer account deletion (5.1.1(v)) (Apple, App Review Guidelines), and Google requires an in-app path and a web link for account deletion (Google). Both stores require privacy disclosures that cover every SDK (Apple, Google). See why Apple rejects apps.
A practical handoff checklist
Before you hire someone to finish your prototype, gather:
- Access to the code repository (export from the AI tool to GitHub if it supports it).
- Access to the database and hosting accounts (Supabase, Vercel, Firebase or similar), under your email.
- A list of every third-party service with its API keys, so they can be rotated.
- A short note on what works, what does not, and what you changed by hand.
- Your target: web only, App Store, Google Play, or all three.
- Your Apple and Google developer accounts, or a plan to create them. See setting up developer accounts for your company.
A real example of a web UI inside a native app
ChairBook, ODEL's appointment app for independent stylists, uses a React and Vite web interface hosted inside an Expo and React Native native shell. It ships on the App Store with native pieces that make it more than a website: StoreKit subscriptions, notifications, Home Screen quick actions, in-app review prompts and over-the-air updates. It is listed in 43 store languages. The same approach works for many AI-built web prototypes, as long as the native features are real.
When ODEL fits, and when it does not
ODEL fits if you have a Lovable, Bolt, Cursor or hand-built prototype and want it reviewed, made secure and published to the App Store or Google Play under your own accounts: see app rescue and maintenance and MVP development. You get a written finish-or-rebuild recommendation and a quote after a discovery call.
A better option might be:
- Keep iterating with the AI tool if you are still changing the idea every week; code review is wasted on a moving target.
- A no-code platform if the product is mostly forms and tables and does not need the stores.
- A larger agency if the prototype is for a regulated field such as banking or health records that needs certified vendors.
If you have a prototype link and a repository, send them over.
