Your Lovable or Bolt prototype works. What to hire for before real users arrive

The short answer

A prototype has to work for one person: you, in your browser, with your test data, on a good day. A live app has to work for strangers, on their phones, with their data, while you are asleep. The code an AI builder produced may be perfectly fine for the first job and still miss what the second one needs.

Before real users touch it, hire for five things: ownership (code, hosting, database and domain in your accounts), a safe place to change it (a test copy and backups), logins and data (one user cannot see another’s), errors you hear about (alerts that reach you), and costs and limits (what it costs at a hundred users, and what breaks first). Order a paid review against that list, then a scoped fix. The AI-built app job page has the brief to start from.

What a prototype is allowed to ignore

When you build with Lovable, Bolt, Replit or a similar tool, the tool optimises for the thing you can see: screens, flows, a working demo. That is the right priority for a prototype. It also means several things were never tested, because nothing in a demo exercises them:

• There is only one user. You. Nobody has tried to open someone else’s page by changing a number in the address bar.
• Nothing depends on it. If it breaks tonight, nobody loses an order or a booking.
• You notice every error. You are looking at the screen when it fails. Nobody will be when a real user hits the same bug at 3 a.m.
• Accounts are wherever they were created. The database might sit inside the builder’s account, the domain might not exist yet, and keys might be pasted straight into the code.
• Changes go straight to the only copy. There is no difference between “trying something” and “changing the live app”.

None of that is a flaw in the prototype. It is the list of what to pay for next.

Five things to hire for before launch

Items 1 and 3 are where most of the risk sits. Who should own the accounts covers the first in detail, and a security check before launch covers the third.

What running a site of my own taught me

I run a site of my own and several unattended automations. None of them is a customer app with user accounts, but the step from “works on my machine” to “runs on its own in public” produced the same kinds of surprises.

Names and accounts are cheapest to settle early. For a site of mine, I checked 26 candidate names for availability, picked one, and then swapped the new name through the code, the preview image, the icon and the documents in a single pass. Later, when a partner program asked me to prove I owned the site, the proof was a screenshot of the domain registration in my own account. If the domain had been registered by someone else, I would have had nothing to show.

A passing build is not proof that every page works. While changing a markdown plugin on a site of mine, I found that if the plugin threw an error, the site still built without complaint and that page’s body went out empty. One page nearly went live like that. The fix was to stop the plugin from throwing at all: it now leaves a marker instead, and the site’s audit treats that marker as a must-fix error.

The live host behaves differently from your machine. When I registered a site with a search engine, I uploaded the verification file it asked for, but the host redirected that address to a version without the file extension, so verification failed. The full note on that redirect shows how small the difference was.

Logins expire after launch, not before. A publishing job of mine kept running on schedule for two days while its access token had expired, and published nothing. Every task reported success. The field note on that token is why item 4 above says alerts that reach you.

None of these needed better code. They needed someone to think about the live environment before it mattered. That is what you are hiring for.

Who to hire, and what to order first

Two kinds of seller work on AI-built apps. Fixers take an app that exists and make it hold up; builders start from an idea. For a prototype that already works, you want a fixer.

Order in this sequence:

1. A paid review against the five items above. Amish Sohail offers a low-cost first review of a vibe-coded site, which is a sensible way to learn the size of the job before paying for fixes.
2. A scoped fix of what the review found, prioritised by item 3 first. Corpsoft is listed for making an AI-built MVP production-ready once real users arrive, and the gig names security and maintenance explicitly.
3. If you want to keep building in the same tool, say so, and consider Haseeb R, who builds with Lovable, Bolt, Cursor and Replit, so the code stays editable the way you work.

On the job page, vetted gigs start at $100 to $250, checked in September 2026, and a starting package usually covers a review or a scoped fix. Making a whole MVP production-ready is quoted per project and runs well above that. In the 197 recent reviews of AI-coding sellers, about half of the orders were $1,000 or more, and 48 of 93 buyers came back for another order. That second number fits what usually happens after launch: the first fix turns into ongoing work, which is worth deciding on purpose, as described in one-off fix or an ongoing developer.

A brief block you can copy

What it is. [One paragraph: what the app does, who will use it, built with (tool).] Code access. [Repository or export on my account.] Which version is live. Goal. Make it ready for real users. Review first against: ownership, a test copy and backups, logins and data access, error alerts, costs at [expected number] users. Then quote the fixes. Sensitive parts. [Logins, payments, personal data, uploads that exist.] Keep editing. I want to keep working in [tool] afterwards: yes / no. Hand-back. Every change in my repository with a note per fix, a README on how to deploy, and a written list of what was checked and what was not. Acceptance. I can log in to every account without you, restore a backup to the test copy, and deploy one small change myself from the README.

The acceptance checklist for fixed AI-built apps has the longer version of that last line.

Where it goes wrong anyway

• You keep prompting the live app. After the fix, a quick change in the builder tool goes straight to production and undoes something. Use the test copy. If changes keep breaking other things, this guide on what to hand the fixer is the next read.
• The review finds the root is wrong. If the data model or the login has to be redone, the honest quote is larger. It is still cheaper now than after a hundred users have data in it.
• Costs grow with users. A service that was free in testing starts billing. Item 5 is there so it is a line in a budget, not a surprise.

Wrap-up

A working prototype is a real achievement, and most of it is usually worth keeping. What it has not done yet is meet strangers. Before it does, pay someone to check the five things a demo never shows, get every account into your name, and make sure the first error a user hits reaches you before it reaches your reviews.