Replit to Production: What to Fix Before Real Users Arrive

Pressing Publish in Replit puts your app on the internet. It does not make the app ready for production. Getting there means five things: separating your development and production data, moving secrets out of the code, choosing the right deployment type, testing the paths where money and personal data move, and deciding honestly whether the code can carry real users. This article walks through each one, and tells you when a rebuild is the cheaper route.

I'm Hanad Kubat, a senior software engineer in Vienna. I take prototypes built with AI tools and turn them into code that real customers can depend on. What follows is what I check first when a founder sends me a Replit app.

Hanad Kubat

Turn Your Replit Prototype Into Real Software

When a prototype hits production limits, I rebuild it as maintainable code with fixed scope, fixed price, and you owning the code from the first commit.

Explore prototype rebuilds

Key takeaways

Publishing is a snapshot of your app in the cloud. It is a release mechanism, not a quality check, so the work of making the app safe still has to be done by someone.
Your development database and production database are separate. Most "it worked in the editor but not live" problems come from data, environment variables or build paths that did not carry over.
The most common serious flaws in AI-built apps are hard-coded secrets and overly permissive access settings. Audit for both before the first real user signs up.
Never give an AI agent unmonitored write access to production credentials. There is a documented case of a production database being deleted this way.
If the app needs payments, logins, a security review or a second developer, an audit of the code will tell you whether to harden it or rebuild it.

What Publishing actually does
Why it works in the editor and breaks when published
Development and production databases
Secrets, access settings and the security basics
Choosing a deployment type
What "production-ready" means beyond the checklist
Fix it or rebuild it
A sensible order of work
My view: a prototype is evidence, not a product
Working with me on a Replit rescue
FAQ
Sources

What Publishing actually does

Replit's own documentation describes Publishing as a simplified way to make your app live, saving a snapshot of it to the cloud where anyone can interact with it. That is useful and it is exactly as much as it claims. It packages what you have and serves it.

What it does not do is decide whether what you have is any good. It will not notice that your login accepts any password, that your admin page is reachable by URL, or that an API key sits in a source file. Replit's publishing guide says as much in its own way: before you open Publishing, test the main user journey, check the layout at the screen sizes you support, and avoid including secrets or private test data in the app.

Think of Publishing as the last step of a release, not the release itself. A release has a few more steps in front of it, and I cover them in my one-page release checklist for staging versus production.

Why it works in the editor and breaks when published

The most common question I see from founders is some version of: everything works in development, and after I deploy, it doesn't. Replit's own community threads show the same pattern, with commenters pointing at environment variables and build paths as the usual suspects.

In my experience the causes fall into four groups.

Environment variables. Secrets and settings exist in the workspace but were never set for the published app, so the live version runs with blanks.
Data. The app in the editor talks to a development database full of your test data. The published app talks to a different, empty one.
Build and start commands. The preview runs a dev server with hot reloading. The published app runs a production build, which is stricter and fails on errors the dev server tolerated.
Hard-coded addresses. Localhost URLs, test payment keys or staging endpoints written directly into the code.

None of these is exotic. All of them are invisible if you only ever look at the preview.

Development and production databases

This is where I spend the most time with Replit projects, because it is where founders lose data.

Replit separates the two databases. The development database is included free with your workspace. The production database is a managed, serverless PostgreSQL instance billed by usage, meaning compute time and storage. The same documentation says production databases go inactive after five minutes without activity, and that storage is measured by maximum monthly usage with a default footprint of 33MB per database.

Two practical consequences follow.

Your test data will not appear in production. If you spent weeks entering real customers into the development database, they are not in the live one. People ask in public forums how to migrate a development database to production after the system created a fresh production database for them. The answer is always the same shape: export what you want to keep, review it, and load it deliberately. Do not copy everything blindly, because development databases tend to contain junk, duplicates and half-finished test rows.

Steps for moving reviewed data into production

The two can get tangled. Replit's page on development and production databases explains the model, and the practical advice is to check your DATABASE_URL after publishing and confirm it points at the production instance. Older published apps may still be connected to a database that was originally created for a different app. Replit has a step-by-step fix for that shared-database case. If your app is older, check this today.

A simple test: create a clearly fake record in the live app, then look for it in the development database. If it shows up there, your environments are mixed.

Backups and the day an agent deleted a database

In 2025 a widely reported incident involved Replit's AI agent deleting a production database. A security write-up on Replit projects notes that agent-generated code can ignore explicit instructions such as a code freeze or an "ask before changing" rule, and concludes that you should never give an AI agent direct, unmonitored write access to production database credentials.

I would put it more plainly. An instruction in a prompt is a request. A permission is a control. If the agent holds credentials that can drop tables, it can drop tables, whatever you told it. For a live app I want three things in place:

A read-only path for anything an AI tool touches while debugging.
Automated backups that you have actually restored from at least once.
Schema changes that go through reviewed migration files, not through chat.

Secrets, access settings and the security basics

Security is the reason I most often see prototypes fail a serious review. SaaStr, writing about this kind of tooling, calls security the number one reason "roll your own" is not yet ready for prime time. I agree with the direction of that argument, though I would add that the fix is usually not exotic. It is a short list of unglamorous checks.

The five-minute check

You can do most of this yourself, in a private browser window so your own login doesn't answer for a stranger.

Open your published address with /.env added at the end, then /.git/config. Neither should return anything. Reeve's guide to checking your own Replit app walks through these and similar checks.
Search your code for key prefixes such as sk- or the names of your payment and email providers. Anything you find in a source file is exposed, and should move into Replit Secrets. The Replit security checklist gives a grep command for exactly this.
Look at your cross-origin settings. A wildcard (*) means any website can call your API from a visitor's browser. Shippable's analysis of public Replit-built repositories flags hard-coded secrets and permissive CORS as common patterns, so check for them before you go live.
Log in as a normal user and try to open another user's record by changing the ID in the URL. If it opens, you have a broken access control, and that is a stop-ship issue.
Check what the app does with a failed payment, an expired session and an empty form. These are the paths real users hit in their first hour.

If you find a key in code, rotate it. Moving it to Secrets does not help if the old value was ever in a public repository or a shared link. Treat it as burned.

Who can open the app

Replit lets you choose an access level when you publish: public, password protected, workspace only or invite only. For a first test with a handful of friendly users, invite-only is a sensible default. Go public when you are ready for strangers, not before.

If your app uses an LLM, there is a second class of risk: users trying to make your model do things you did not intend. I wrote about this in prompt injection defense and why architecture comes before guardrails.

Choosing a deployment type

Replit offers four deployment types. The deployment types documentation lays them out, and this is my plain-language reading of it.

Type	Good for	How it behaves	How you pay
Autoscale	Web apps and APIs with uneven traffic	Adds servers when busy, scales to zero when idle	While requests are being served
Static	Landing pages, portfolios, docs	Serves files with no backend	For the data served
Reserved VM	Bots, background work, always-on APIs	One dedicated server that never sleeps	Fixed monthly cost
Scheduled	Backups, notifications, periodic jobs	Runs a command on a schedule, then stops	For the duration of each run

A few notes from practice:

Apps created with Replit's agent are full-stack and need a backend, so the documentation says Static is not compatible with them. Autoscale or Reserved VM is the choice.
Autoscale is the default and the documentation recommends it for most builders. It suits uneven traffic, but a scaled-to-zero app can be slow on the first request after idle time. If your users are paying customers waiting on a page, test that first load.
If your app does background work, such as sending email queues or processing uploads, Autoscale is usually the wrong home for it. A Reserved VM or a Scheduled job is a better fit.

What it costs

Replit reduced its cloud prices on August 1, 2026, and the new prices apply automatically at the start of your first billing cycle on or after that date. Billing is usage-based, so the honest answer to "how much will this cost" is that it depends on traffic, compute time and storage. Read the publishing costs page for current rates, because they have just changed and I would not trust a figure quoted from memory, including mine.

What I tell founders is to set a spending alert, run realistic traffic for a week, and then decide whether the bill is acceptable. If it is already absurd at low usage, that is a sign the app is doing too much work per request, which is a code problem rather than a pricing problem.

Where your data lives

Replit hosts published apps primarily in the United States. According to its geography documentation, Core, Pro and Enterprise customers can pick another publishing region, including Europe, to reduce latency and meet data residency needs. The setting is permanent once the project is published.

That last point matters. If you serve customers in the EU, or you are a European business, decide on the region before the first publish, not after. Whether that setting alone satisfies your obligations under GDPR is a question for your data protection adviser, not for a hosting dropdown.

What "production-ready" means beyond the checklist

The list above gets a small app from fragile to reasonable. A real production setup goes further. Google's guidance on managing ML projects in production describes automated pipelines, independent testing and continuous monitoring as standard practice for serious systems. That guidance is written for machine learning, but the principle carries over to any app that handles money, health data or client records. One-click deployment is a convenience, and it is not a substitute for those practices.

In practical terms, I look for these in a codebase before I call it ready:

A repeatable deployment. Anyone on the team can ship the same way every time. I explain the moving parts in what a deployment pipeline is.
Error tracking and uptime alerts. You hear about a failure before your customer emails you.
Tests on the paths that cost money. Sign-up, checkout, subscription changes, refunds and password reset.
A staging copy. A place to try changes that is not the live app.
Code someone else can read. Consistent structure, no 2,000-line files, no logic duplicated in six places.

The last one is where prototypes often fail. A Replit app can run perfectly and still be a maze to extend.

Fix it or rebuild it

This is the decision founders find hardest. They have something that works, and I am about to ask whether it should be kept.

One study reported by the American Impact Review found that high technical debt, often introduced during rapid prototyping, correlates with a 23% reduction in delivery velocity and a 31% increase in defect density in enterprise settings. Those are enterprise figures and your two-person startup is not an enterprise, but the direction is familiar to anyone who has tried to add a feature to a tangled prototype. For the concept in plain terms, see my piece on startup technical debt for founders.

My rough rule is this.

Harden it when the structure is sound, the data model makes sense, and the problems are the checklist items above: secrets, access control, environments, a few missing tests. That is days of work, not weeks.

Rebuild it when any of these are true:

Every new feature breaks an old one.
The data model is wrong, for example everything stored in one table or one JSON blob, and fixing it means touching everything.
You need to pass a customer's security questionnaire or an investor's technical review, and the honest answer to several questions is "we don't know".
Nobody except the AI tool can explain how a piece of the app works.
The platform bill is growing faster than your revenue.

When I rebuild, the prototype becomes the specification. It has already told us what users do, what the screens look like and which workflow matters. I rebuild that workflow as ordinary, maintainable code. My rewrite versus refactor rubric scores this decision on eight points, so you can run it yourself before talking to anyone.

If a review is the next hurdle, read what SaaS founders must prove to pass a security review and the software due diligence checklist first. The same ownership questions apply whichever tool built the prototype. My handoff guide for a Lovable build covers them in detail, and most of it transfers to Replit.

A sensible order of work

If you want to go live with a Replit app this month, this is the order I would follow.

Freeze the scope. Pick the one workflow that matters. Everything else waits.
Back up and export. Get your code into a repository you control and export your data.
Rotate and relocate secrets. Assume anything ever pasted into a prompt or a file is compromised.
Separate environments. Confirm the live app uses the production database and that test data stays in development.
Lock down access. Fix cross-origin settings, check every route for authorization, and start invite-only.
Pick the deployment type and region. Decide on Autoscale or Reserved VM, and choose the region before publishing.
Test the money and identity paths. Payment, login, password reset, deletion of an account.
Add monitoring and a backup you have restored.
Open the door slowly. Ten users, then fifty, watching errors and the bill.

That sequence is deliberately dull. Production is mostly dull things done in the right order.

My view: a prototype is evidence, not a product

I have spent ten years in software, including systems work for Deutsche Bahn, BMW and the Austrian Federal Computing Centre (BRZ). The lesson that carries across all of it is that software fails at its edges: the second user, the failed payment, the person who clicks back. Prototype tools are brilliant at the middle of the path and silent about the edges.

That is not a criticism of Replit. A prototype that proves people want your product is worth a great deal. But it proved demand, not durability. I would rather tell you that plainly than sell you a rebuild you don't need. If a handful of fixes will carry your app, I will say so, and I will say if an off-the-shelf tool fits your problem better than custom code.

When a rebuild is right, I do it as one person with fixed scope and a fixed price, and you own the code from the first commit. The stack is deliberately boring, TypeScript, Next.js, Node and SQL, so the next developer you hire can pick it up without a translation exercise.

— Hanad Kubat

Working with me on a Replit rescue

If your Replit app has hit a wall, whether that is data in the wrong place, a failed review, a bill that makes no sense or a codebase nobody can extend, I can look at it with you. I build the first real version of software products for founders and owner-operated businesses: fixed price, fixed scope, two to four weeks, built end to end by me. Builds start from €12,000, and that price is possible because there is no agency overhead, no project-manager layer and no offshore markup.

You see working progress before you pay for it. You can see how it works and what I offer on my main page, or read it in German on the Festpreis page for Vienna.

FAQ

Is Replit good enough for production apps?

For a small internal tool or an early pilot with a few known users, it can be. For a product with paying customers, personal data or an upcoming security review, treat the Replit version as a prototype and plan for a hardening pass or a rebuild. The deciding factors are your data sensitivity and how soon you need a second developer to work on it.

How do I move my Replit development database to production?

Export the data you actually want, clean out test rows, and load it into the production database on purpose. Do not assume the two sync, because Replit keeps them separate. After publishing, confirm the DATABASE_URL points at the production instance, and test with a fake record.

Can I deploy a Replit app for free?

You can build and test in the workspace, and the development database is included. Published apps and production databases are billed by usage, so a live app is not free in practice. Check Replit's current publishing costs, as rates were reduced from August 1, 2026.

Where are Replit's servers located?

Published apps are hosted primarily in the United States. Core, Pro and Enterprise customers can choose another publishing region, and the documentation says that choice is permanent once the project is published, so decide before your first publish.