If you built an app with Lovable, Bolt, Claude Code or Cursor and it works in a demo, you have already answered the first question about the idea: can it be shown, clicked and explained to someone? What a demo does not prove is that the app is safe to give to strangers who will put real data and money into it. The gap between the two is usually the same short list: who can see which data, what happens when a payment or an email fails, where the data lives, and who controls the accounts. Some prototypes can be brought across that gap. Others are cheaper to rebuild, with the prototype kept as the specification.

What these tools are good at

AI app builders are good at the part of a product that used to be slowest: turning an idea into screens that people can try. A founder can now put a working flow in front of ten potential customers in a week, without hiring anyone, and learn whether they want it. That is worth a lot. Most product ideas should be tested exactly this way before anyone spends serious money on them.

The tools also produce real code. Lovable, for example, says the code you create is yours and lets you sync it to a GitHub repository. So a prototype is not throwaway by default. Whether it is worth keeping depends on what is inside.

Where a prototype usually breaks

Who can read which data

This is the item to check first. Many AI-built apps use Supabase as their database and talk to it directly from the browser. That design is safe only if every table has Row Level Security switched on, with policies that say which user can read and change which rows. Supabase's own documentation says to enable RLS on every table in an exposed schema.

When that is missing, anyone who opens the browser's developer tools can query the database. In 2025 this was registered as CVE-2025-48757: insufficient row-level security in apps generated by Lovable up to 15 April 2025 let unauthenticated visitors read or write arbitrary tables. Lovable disputes the CVE on the grounds that each customer is responsible for protecting their own application's data. Whoever is right about responsibility, the practical point is the same for every tool: the policies are part of your app, and they are only as good as the last time someone read them.

Keys belong on the same checklist. A publishable key in the browser is normal. A secret key there is not: Supabase says never to use a secret key in the browser, and Stripe says not to embed API keys or webhook secrets in source code or client-side applications.

Roles and accounts

A demo usually has one kind of user. A product has at least two: the customer and you, the admin. Often more, such as a company account with colleagues, or a client and a supplier who must never see each other's records. Adding roles late means revisiting every screen and every database policy, which is why it is the most common reason a prototype gets rebuilt.

The data model and migrations

In a prototype, the database structure changes whenever you ask for a feature. Once real customers have data in it, every change has to be a migration that keeps what is already there. Look at whether your project has migration files that describe how the database got to its current shape, and whether a field that holds money, dates or status has a clear type and meaning. If tables were reshaped by prompts many times, it is often quicker to design the model again than to untangle it.

Payments

Taking a test payment is easy. A real payment flow also has to handle the card that is declined, the customer who closes the tab before the confirmation page, the refund and the subscription that renews. With Stripe, that means a server-side event handler that verifies each event's signature before it marks anything as paid. If the prototype only updates a "paid" field from the browser, the payment part needs to be rebuilt.

Emails

Sign-up confirmations, password resets and invoices have to arrive. Since 1 February 2024, Gmail requires every sender to authenticate with SPF or DKIM, and senders of more than 5,000 messages a day need SPF, DKIM and DMARC. That means sending from your own domain through a proper email provider, with DNS records you control.

GDPR and where the data lives

Once you store personal data about real people, the GDPR applies to you, not to the tool. Every service that processes that data for you (database host, email provider, analytics) needs a data processing contract under Article 28, and a personal data breach must be reported to the supervisory authority within 72 hours of becoming aware of it, where feasible (Article 33). Check which region your database runs in: Supabase deploys each project to one primary region, and its list includes EU regions such as Frankfurt, Paris and Ireland alongside London and Zurich, which are outside the EU.

Errors, tests and cost

A prototype fails silently. A product needs error monitoring, so you hear about a crash before a customer emails you, and tests on the few paths that matter most: sign-up, the core workflow and the part that takes money. Also check how the backend is billed. Usage-based services cost little with ten users; look at the pricing pages of each service you depend on and work out what a thousand active users would cost before you promise a price to your own customers.

App stores, if it is mobile

If the plan is to put a wrapped web app in the App Store, read Apple's guideline 4.2 first: an app should go beyond a repackaged website. Both stores also require that an app which lets users create an account lets them delete it, inside the app on iOS and, on Google Play, in the app and through a web link.

Who owns the accounts

Make a list of every account the product depends on: the builder, the GitHub repository, the database, the domain, Stripe, the email provider, the Apple and Google developer accounts. Each one should be in your company's name, with your email as the owner. Note that the code is only part of it. Lovable's FAQ says its database export does not include stored files, Edge Function code or secrets, and its hosting guide says that moving the database alone does not move authentication, storage, realtime or Edge Functions. Plan for those separately if you ever move.

Keep it or rebuild it?

The prototype is probably worth keeping if:

the code is in a Git repository you control, with a readable history;
RLS (or an equivalent server-side check) is on for every table, and the policies match who should see what;
the database has migration files and a structure you can explain;
no secret keys are in the browser code;
it already has the roles you will need, or adding them touches a small part of it.

A rebuild is usually cheaper if:

the data model was reshaped by many prompts and nobody can say what each table is for;
you need roles or multi-company accounts that the prototype never had;
payments are confirmed from the browser;
each new prompt breaks something that worked before.

A rebuild does not throw the prototype away. It is the clearest specification a developer can get: the screens, the flow and the decisions you already tested with users. Often part of it survives, such as the interface components.

What a handover to a studio looks like

You give access to the repository, the database project and the accounts listed above, plus a short note on who the users are and what they must be able to do. The studio reads the code, runs it, checks the items in this article and tells you what it would keep, fix or replace, and at what price. Then it either finishes the existing product or builds the first proper version from scratch.

We do both. Our web-app MVP is €14,000 excluding VAT, in 8–10 weeks: one core workflow, accounts and authentication, a simple admin, one integration or payment path, tests on the critical paths, deployment, monitoring and documentation, with the repository and accounts in your name. It is web first: native iOS and Android apps, extra integrations, extra languages and data migration are fixed-price add-ons, quoted before we start. The full list is on the MVP page and the pricing page.

We also take over products other developers started. For Getizy we took over an existing iOS and Android app from the previous development company, fixed the bugs and technical debt we inherited and kept shipping new features to both stores. A takeover begins with a paid review of the code, the Product Decision Sprint (€2,500, 5 business days), credited in full against a build that starts within 30 days. The fixed quote comes after that review, based on what is actually in the repository.