Guides / Solo pros and consultants
How to finish a Lovable or Bolt prototype that almost works
Finish an almost-working Lovable or Bolt prototype by listing exactly what fails, fixing the small things inside the builder, and handing the structural things (logins, saved data, payments, email, hosting) to a person who can read the code. Most prototypes are closer than they feel, but the last stretch is a different kind of work than the first.
Why the last 20% is the hard part
AI builders are good at producing screens that look right and work on the happy path. You click through the demo, it behaves, and it feels done. The gaps show up when a real person uses it: someone enters a strange value, refreshes mid-way, opens it on a phone, or tries to log in a second time.
The remaining work is usually not more features. It is the unglamorous parts that make an app dependable: data that saves and stays saved, permissions that keep people out of each other's records, errors that say something useful, and a deployment that does not depend on your builder session.
Triage before you prompt again
The most common mistake is typing another prompt every time something looks off. Each prompt can change code you did not mean to touch, and a project that was 90% working can slide backward. Spend 30 minutes testing first and write down what you find.
Go through the app as if you were a stranger, on both a phone and a laptop, with a fresh browser profile. Sort every problem into one of three piles: cosmetic, broken behavior, or missing foundation.
- Cosmetic: spacing, wording, colors, a button in the wrong place.
- Broken behavior: a form that does not submit, a filter that returns the wrong rows, a date that shows the wrong day.
- Missing foundation: no real login, data that vanishes on reload, secret keys visible in the code, no way to send email, no live domain.
- Unknown: things you cannot tell because you have not tested them yet, such as what happens with 200 records or two people editing at once.
What you can fix yourself
Cosmetic issues and many behavior bugs are fair game inside the builder. Make one change per prompt, say exactly what you expect to happen, and test right after. If something gets worse, roll back to the previous version instead of asking the tool to undo its own change.
Paste in the actual error message when there is one, and describe the steps that cause it. Vague requests like "make it work better" tend to produce wide, risky edits. Keep a short written list of what is working so you notice when something regresses.
- Make one change at a time and test it before moving on.
- Use version history or export to your own repository so you can always go back.
- Do not paste passwords or secret keys into the chat.
- Stop if you are going in circles. Three failed attempts at the same bug is a signal to change approach.
When to bring in a developer or a service
Foundation problems are where builders tend to stall. Real authentication, role permissions, storing data safely, taking payments, sending email, and putting the app on a stable host all involve decisions that a prompt cannot fully verify. You may get something that looks like it works while a security or data problem sits underneath.
You have a few honest options. A freelance developer can review the code and finish it, usually billed hourly or by project, and the cost varies widely by person and scope. A friend who codes can do a quick review, though open-ended favors tend to drag. Or you can rebuild the idea in a no-code tool, which works if the app is mostly forms and tables but means starting over. Whoever you pick, hand over the code export, a short list of what must work, and a few example records.
Where a fixed-price build fits
If you want the project finished rather than rebuilt, we do this as a fixed-scope job. You send us your prototype and a short brief, we send a working preview within one business day, and we finish the parts that are not holding up. You get the hosted link and the full source code, so nothing is locked to us. Our page for this is "Finish your AI prototype."
Pick the tier by how much is left. Micro is $249 and takes 3 business days: one single-purpose tool, up to 2 screens, no login, one round of tweaks. Tool is $749 and takes 5 business days: saved data, up to 5 screens, one integration such as email, Google Sheets, or Stripe, and two rounds of tweaks. Mini-app is $1999 and takes 10 business days: logins and roles, up to 10 screens, up to 2 integrations, your domain or ours, three rounds of tweaks, and 30 days of bug fixes.
Hosting is included for 12 months, then $9.00 per month, or you can self-host. If we decline your project before work starts, you get a full refund. After delivery there is no refund, so check the preview carefully while you can. If your prototype is big, or the idea is still changing every day, we may say it does not fit a fixed scope, and that is better to learn before work starts.
Check these before you share it
Whoever finishes the app, run the same short test before real people use it. Create a record, reload the page, and confirm it is still there. Log in as two different people and make sure neither can see the other's data. Submit a form with empty and odd values. Open the live link on a phone you are not logged in on.
Then confirm the boring operational pieces: where the data lives, who owns the accounts, how you would export it, and who gets notified when something fails.
- Data survives a page reload and a new session.
- Secret keys are not exposed in the browser code.
- Emails and payments work in the live version, not just in preview.
- You have the source code and know where the app is hosted.
- There is a plain way to reach you when someone hits an error.
An almost-working prototype usually needs a clear list, a few careful fixes, and someone to handle logins, saved data, and hosting properly. Test it like a stranger, fix the small things one at a time, and bring in help when the problems are about the foundation, not the look.
Related examples
- Public directory page powered by a Google SheetReal build · Micro
- Opening and closing checklists for a cafe crewReal build · Tool
- Photo proofing galleries with client picks and remindersReal build · Tool
Want this built for you? Describe it and we'll scope it in a minute.