Home AI Development AI App Builder Audits Replit

AI App Builder Audits · AI Development Series

Replit App Audit

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.

Rob Sherwood, co-founder of Dev Partners
Straight answer: we do not build on Replit and we are not Replit consultants. What Replit Agent hands you is ordinary code — React, Express, Flask or Django with a Postgres database — and that is engineering we have been doing for years. We audit the output, not the tool.

What Replit actually hands you

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.

The stack Replit Agent generates

  • Frontend Usually React, often with Next.js
  • Backend Node with Express, or Python with Flask or Django
  • Database Postgres, or the built-in Replit key-value store
  • Authentication Scaffolded as part of the build
  • Secrets Replit's own secrets manager
  • Hosting Replit Deployments, live on a URL immediately

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.

What we consistently find

These recur across Replit projects regardless of which stack the Agent picked.

1

A key-value store doing a relational database's job

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.
2

An application that only knows how to run on Replit

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.
3

State held in memory that will not survive

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.
4

Secrets that did not stay secret

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.
5

Login working, but not protecting everything

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.
6

No way of knowing when something has gone wrong

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.

Where Replit is genuinely good

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.

Genuinely well suited to

  • Learning to build software, and teaching it
  • Prototypes and experiments that need to be live for someone to try
  • Internal tools for a small, trusted team
  • Getting something in front of users before committing a budget
  • Anything where speed matters more than longevity

Where it needs engineering behind it

  • Multiple separate customers whose data must never mix
  • Anything holding personal data, health data, or payment details
  • Applications that need to survive restarts and handle real load
  • Anything your business would genuinely suffer without
  • Software you may one day need to run somewhere else

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.

Rob Sherwood, co-founder of Dev Partners

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.

Rob Sherwood
Co-founder, Dev Partners
Meet the team

Prefer to watch? The short version of who we are and how we work

Do you need an audit?

Get it looked at if

  • More than one customer or organisation uses it
  • It stores personal data of any kind
  • It takes payments or sits near anything that does
  • You are wondering what leaving Replit would involve
  • It has started behaving differently at busy times

You are probably fine if

  • You are the only person who uses it
  • It holds nothing you would mind losing or leaking
  • It is a learning project or an experiment
  • It is a throwaway you will rewrite when the idea is proven

The AI Code Audit, applied to your Replit app

Fixed price, £495. A written report within five working days of getting access to the code. We look at four things every time: security and access control, database structure, whether it will scale, and whether it can be maintained — and for Replit projects we also tell you honestly what moving off the platform would involve. If you go on to have us fix it or rebuild it, the £495 comes off the cost in full.

Questions about auditing a Replit app

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.

Find out what you are sitting on

The AI Code Audit is £495, fixed.

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:

  • Security and access control across every route
  • Database structure and whether it fits the business
  • Whether it will hold up as usage grows
  • What moving off Replit would actually involve

We reply within one working day.

Book the audit