AI App Builder Audits · AI Development Series
Replit made it easy to build and trivial to deploy. The questions worth answering are what the code is doing, and what it would take to run it anywhere else.
Replit is unusual in this category because it is a full environment rather than just a generator. The Agent writes the code, provisions a database, wires up authentication, manages your secrets and deploys the result — all in the same conversation. That is a genuinely impressive piece of engineering and it removes an enormous amount of friction.
Because it chooses a stack per project rather than always producing the same one, there is no single Replit failure mode in the way there is with Lovable. What we find depends on what it built. An Express and Postgres application has different weak points from a Django one.
What is consistent is the second question, and it is the one people rarely think to ask until they need the answer: how much of this application assumes it is running on Replit? The code is yours and you can download it. Whether it will start up somewhere else without a fortnight of work is a separate matter entirely.
These recur across Replit projects regardless of which stack the Agent picked.
Replit's built-in database is a key-value store. It is quick, it needs no setup, and for configuration or simple caching it is exactly right. It is not designed to hold data with relationships in it.
When an application ends up storing customers, orders and line items in it, everything has to be assembled by the application code — reading several keys, stitching them together, and hoping nothing changed in between. There is no way to ask it a question that spans records, no transactions, and nothing preventing two operations from overwriting each other. This is the same underlying mistake as a relational database with far too few tables, just wearing different clothes.
What it costs you: data that silently drifts out of step, and reports you cannot trust.You own the code, and Replit does not attempt to trap you — but generated applications tend to lean on the environment in ways that are invisible until you try to leave. Paths that assume Replit's filesystem. Configuration read from variables the platform happens to set. Database connections pointing at a service that only exists inside it. Files written to local disk that vanish on redeploy.
None of these are hard problems individually. Together they are the difference between "move it to a normal host over a weekend" and "budget three weeks". Part of the audit is simply telling you which of those two you are looking at, before the question becomes urgent.
What it costs you: an unplanned migration project at the worst possible moment.Generated code frequently keeps things in a variable in the running process — a session, a cache, a counter, an uploaded file. On a single instance that has not restarted, this works flawlessly.
It stops working the moment the application restarts, which deployments do routinely, and it breaks in a much more confusing way if you ever run more than one copy to handle load: users get logged out at random, depending on which instance answered them. This is one of the most common reasons an application that "worked fine" starts behaving erratically shortly after it gets busy.
What it costs you: intermittent, unreproducible faults that appear exactly when traffic grows.Replit provides a proper secrets manager and the Agent generally uses it. What we look for is everything that went around it: an API key pasted directly into a file during debugging and never removed, credentials committed into the project history, or — the one that matters most — a key that is genuinely secret but gets sent to the browser, where anyone can read it out of the page.
Third-party keys for payment, email and AI services are the usual casualties, and the first sign of trouble is normally an unexpected bill.
What it costs you: somebody else spending your money on your accounts.Authentication gets scaffolded early and tends to be correct where it was first applied. The gaps appear in what came afterwards: an API route added later, an administrative page, a file download, an endpoint built to serve one screen and never revisited.
As with any generated application, we go through every route and check what it requires before it will respond, rather than trusting that the login page implies the rest is covered.
What it costs you: data reachable by anyone who knows or guesses the address.Deployed applications rarely arrive with error tracking, alerting, or any automated tests. If something fails for a customer overnight, nothing tells you. The first you hear is a complaint, or worse, silence and a customer who quietly left.
It also means every subsequent change is a gamble, because there is nothing to catch you if you break something that used to work.
What it costs you: problems you find out about last, and changes you cannot make with confidence.Replit deserves a lot of credit. It has done more than almost anyone to remove the setup barrier that stops people building things at all, and the experience of going from an idea to something live on a URL in an afternoon is remarkable. It is also honest about producing real code that you own.
The honest summary: Replit is excellent at getting you to something that works and running. The gap is between "running" and "dependable", and that gap is invisible from inside the environment — everything looks green right up until the day it does not.
The question we get asked most about Replit is not "is my code any good", it is "am I stuck here". It is a fair question and it deserves a proper answer rather than a sales pitch. Sometimes the answer is that you could move it next week. Sometimes it is not. Either way you should know which.
Not in the way you would be with a proprietary no-code platform. The code is standard and it is yours, and you can export it. What varies is how much the application has come to depend on Replit's environment along the way — its filesystem, its database, its configuration. Sometimes that is a day's work to untangle and sometimes it is a few weeks. The audit tells you which, so it is a decision rather than a discovery.
Often not, and we will not push you to. Replit Deployments are perfectly reasonable hosting for plenty of applications, and moving for the sake of it is wasted money. The reasons that genuinely justify a move are usually specific: cost at your scale, a compliance requirement about where data lives, or a need for infrastructure the platform does not offer. If none of those apply to you, staying put is a sensible answer and we will say so.
Access to the code, either by inviting us to the Repl or by exporting it to a GitHub repository, and ideally read-only access to the database. We do not need your account credentials, we will not deploy anything, and we will not change your application. If you would rather send us a code export and nothing else, we can work with that too, we simply see less.
No, and we would rather say so plainly than pretend otherwise. We build with Claude Code and Cursor, with senior developers designing the system, reviewing every change and testing it. What makes us useful here is not Replit expertise, it is that Replit produces React, Node, Python and Postgres, which is what we have been building and fixing for years.
For some of them, yes, and where that is the sensible route the report will say so plainly. The problem is knowing precisely what to ask for. A generator asked to "make it production ready" will produce something that looks more production ready, and you have no independent way to check. The audit gives you the specific list, in priority order, which is the part the tool that wrote the code cannot give you about itself.
We audit what these tools produce, whichever one you used.
Tell us roughly what the application does and how many people use it. If an audit is not the right thing for you, we will say so.
What the report covers:
We reply within one working day.