Prototype → production

Your prototype works. Production is a different question.

You built something real in Lovable, Replit, Bolt, v0 or Emergent — and it works. Then you try to put it in front of paying customers and discover the app was standing on things that were never meant to leave the preview. mvpfy finds them, tells you in plain language what each one would do on launch day, and helps you fix them.

The short answer

An AI-built prototype is usually not production ready, and it is not because the code is bad. These tools optimise for showing you something working quickly, so they leave the shortcuts that made that possible: a demo account seeded so you could click around, sample data in the same database as real records, payments in test mode, placeholder API keys, and features switched off to keep the preview light.

None of that matters until a stranger arrives. Then each one is a way to lose money, lose data, or let someone in who should not be. The fix is almost never a rewrite — it is replacing the stand-ins with real things. The hard part is knowing which ones are in there.

What actually breaks

Not theory. These are the findings that come up again and again on prototypes that have never met a real user, in rough order of how often they bite.

The demo login still works

blocker

The email and password you used while building are still valid, so anyone who finds your site can sign in as a full user and see every customer's data. It is the single most common one, because you need that account right up until the day you don't.

To fix — delete the demo account and its seeded rows before the first real sign-up.

Your database is wiped every time you deploy

blocker

The data lives in a file inside the container that runs the app, which is thrown away on each deploy. It looks fine right up to your first update, at which point every customer's account disappears — and there is no backup, because nothing was ever configured to make one.

To fix — move to a managed database with backups turned on, and load the schema rather than replaying migrations.

Checkout does not take real money

blocker

Payments run against test keys or a mock service that always approves. A customer gets the product, you get no money, and there is no record that it happened.

To fix — connect the real payment account and switch to live keys, then test one real transaction end to end.

The session secret is a placeholder

risk

It is the same value in every copy of the code — often the same value in every project the tool has ever generated — so someone can forge a login as any user.

To fix — generate a real secret and store it with your host, never in the repository.

Features were switched off to make it run

risk

Search, file uploads, email — anything that needed a service too heavy for a preview gets quietly disabled. The buttons are still there. Customers click them and get nothing.

To fix — connect the real service, or stop offering the feature in the interface until you do.

You would not know when it breaks

risk

No error tracking, so a failing checkout is silent. You find out when a customer bothers to tell you, which most of them will not.

To fix — add an error tracker before you send anyone to the site.

Why mvpfy can answer this

Most tools that audit a codebase are guessing about intent. mvpfy is not, because it set the app up in the first place.

When you add a project, mvpfy works out everything the product needs to run and fills in whatever is missing — a database, a mail inbox, a stand-in for a payment service that cannot run offline. It writes down what it faked and why, in plain language, as it goes. So when it later tells you "checkout is not real", it is not inferring that from the code. It knows, because it is the thing that made it pretend.

That report is graded, and mvpfy is strict about the grading: a blocker means real people lose money, lose data, or get access they should not have. Every finding points at the file that proves it, so you can check the claim rather than trust it. And you can decide to launch with something anyway — it stays on the list, marked as your decision, because accepting a risk does not make it safe.

How to take a prototype to production

  1. Get the code onto GitHub

    Lovable, Replit, Bolt, v0 and Emergent can all push your project to a GitHub repository. Do it. From that moment the code is yours and stops depending on their editor — which is the actual lock-in, not the code itself.

  2. Run it on your own machine

    Add the repository to mvpfy. It reads the code, works out every service the app needs, writes the Docker setup, fills the gaps, and starts the app with a login you can use. If it cannot run outside the tool that built it, you learn that here rather than on launch day.

  3. Check launch readiness

    mvpfy audits the app and reports what would go wrong with real users — graded, in plain language, each finding pointing at the file behind it.

  4. Fix the blockers

    Work down the list. Describe each fix in plain language and the agent applies it, or hand the list to whoever helps you with code. Either way you now know what the list is.

  5. Deploy, then keep shipping

    The Dockerfile mvpfy generated is exactly what a host like Fly, Render or Railway wants. After launch, the same loop keeps working: describe the change, see it running, ship it.

Download for macOS · beta View on GitHub

Free and MIT-licensed. Runs on your machine — your code is not uploaded anywhere. Bring your own agent (claude).

Questions people actually ask

Is a Lovable or Replit app production ready?

Usually not as it stands, and not because the code is bad. The shortcuts that let you see something working in an afternoon — seeded demo accounts, sample data, test-mode payments, placeholder keys, disabled features — are exactly the things that hurt once a stranger arrives. They are all fixable, and none of them require a rewrite.

Do I have to rewrite my app?

Almost never. The work is replacing stand-ins with real things and deleting the demo data that let you click around. That is a specific list of changes. The danger is not knowing which shortcuts are in there.

How do I move off Lovable or Replit?

Push to GitHub, then prove the app runs somewhere that is not their environment. Once it runs on your machine in Docker, it will run on any host — and you are no longer waiting on anyone's export button.

Can I do this without being technical?

The readiness report is written for the person who built the product, not for an engineer — it says what each finding means for your customers, not which config key is wrong. Fixing them is plain-language instructions to an agent. Setting the tools up the first time is the one step where an engineer friend helps; mvpfy installs most of them for you on macOS.

Does my code get uploaded anywhere?

No. mvpfy has no server. Your repository is cloned to your machine and the app runs in Docker locally. Code reaches a model API only through the AI agent you installed and signed in yourself, under your own account.

What does it cost?

mvpfy is free and MIT-licensed. Agent work bills to your own Anthropic account, the same as using Claude Code directly.