AI App Builder Audits · AI Development Series
Emergent App Audit
Emergent builds fast and it builds a lot. An audit tells you which of those decisions will hold up once real people are using the thing.
What Emergent actually hands you
Emergent works differently to most generators. Rather than one model writing everything, it runs a set of specialised agents — planning, frontend, backend, testing, deployment — that each take a stage. The result syncs to GitHub as real, portable code, which is genuinely to its credit and is what makes a proper review possible.
The stack Emergent generates
- Frontend React, usually styled with Tailwind
- Backend Python, using the FastAPI framework
- Database MongoDB
- Mobile Expo and React Native, where mobile is in scope
- Validation Pydantic models on the API boundary
- Hosting One-click deployment, with storage included
The important structural difference from a tool like Lovable is that there is a real backend here. Your React application does not talk to the database directly; it goes through FastAPI endpoints. That is a better shape, because it gives you a single place where access rules can be enforced properly.
The catch is that FastAPI does not enforce anything by default. Protection is applied per route, one endpoint at a time, and it is entirely possible to build an application where nineteen endpoints check who you are and the twentieth does not. That twentieth endpoint is what an audit is looking for.
What we consistently find
These are the issues that recur in generated FastAPI and MongoDB applications, in roughly the order of how much trouble they cause.
Endpoints that forgot to ask who you are
FastAPI protects a route when you attach an authentication dependency to it. Miss that off a route and it is simply public — no warning, no error, and the application works perfectly for anyone testing it while logged in.
Generated code tends to get this right on the obvious endpoints and miss it on the ones added later: an export, a reporting endpoint, an administrative action, something built to fix a bug at the end of a session. We go through every route and check what it requires before it will answer.
What it costs you: one unprotected endpoint is enough to expose the data behind all the protected ones.Authenticated, but not authorised
A subtler version of the same problem, and more common. The endpoint correctly establishes that you are logged in, then takes a record identifier straight from the request and returns that record — without ever checking that it belongs to you.
Every legitimate user of the application will only ever request their own records, so nothing looks wrong. Changing one number in a URL is all it takes to read somebody else's. Knowing who someone is and knowing what they are allowed to touch are two separate checks, and generated code very often does only the first.
What it costs you: customer data exposed to other customers. Reportable to the ICO under UK GDPR.MongoDB guarantees nothing about your data
MongoDB will accept whatever you give it. There is no enforced schema, no required fields, and no referential integrity unless the application supplies it. That flexibility is the point of the database, and it is genuinely useful — but it means the only thing standing between you and inconsistent data is the code, every single time.
In practice we find collections where the same information is copied into several documents so it can be read back quickly, and then updated in only some of them. Records referring to things that were deleted months ago. Fields that are a string in older documents and a number in newer ones, because the shape changed halfway through the build and nothing migrated the old data.
What it costs you: reports that quietly disagree with each other, and no obvious way to tell which is right.Collections with no indexes
Mongo will scan an entire collection to satisfy a query if there is no index to help it, and it will do so without complaint. During a build, with a few dozen test documents, this is instant. It stays instant right up until it is not.
We check which queries the application actually runs and whether the indexes exist to support them — including the aggregation pipelines, which are where generated code tends to do the most expensive work.
What it costs you: the application slows down in proportion to your success.Tests that were written by the thing being tested
Emergent's testing agent does produce tests, which puts it ahead of most generators. The difficulty is what those tests are for. A test written by the same process that wrote the code tends to describe what the code does rather than what the business needs it to do — so if the behaviour is wrong, the test faithfully asserts the wrong behaviour and passes.
A green test suite is genuinely reassuring when it encodes real requirements. It is actively misleading when it does not, because it gives you confidence to make changes you have no actual safety net for. We read what the tests are claiming, not just whether they pass.
What it costs you: false confidence, which is worse than no confidence.Validation at the front door only
Pydantic models are a real strength of FastAPI and generated code usually does define them. What we find is that they are often applied to the request coming in and then ignored thereafter, so data assembled internally, imported in bulk, or written by a background job goes into the database unchecked.
The result is a collection where most documents are well-formed and a minority are not, and code that assumes the first case. Those are the errors that appear at random, cannot be reproduced, and take days to track down.
What it costs you: intermittent failures that nobody can pin down.Where Emergent is genuinely good
Emergent is one of the more serious tools in this category. It produces a real backend rather than pushing everything into the browser, it exports portable code with no proprietary lock-in, and the multi-agent approach means it covers ground — deployment, testing, mobile — that most generators leave to you.
Genuinely well suited to
- Getting a complete full-stack prototype standing up quickly
- Teams already comfortable in Python who will maintain it themselves
- Testing a product idea end to end, including on mobile
- Internal tools with a small, trusted set of users
- Producing a working reference for developers to build properly from
Where it needs engineering behind it
- Multiple separate customers whose data must never mix
- Anything holding personal data, health data, or payment details
- Data that has to stay consistent and reconcile correctly
- Applications expected to grow well beyond their first users
- Anything that has to keep being changed safely over years
The honest summary: Emergent gets you further than most before the problems start, and the problems it leaves are the ones that only appear under real conditions — several customers, real volume, real money. That is exactly the point at which finding out the hard way is most expensive.
The thing that catches people out with Emergent is that it produces a proper backend, so it feels like a proper application — and mostly it is. But a generated test suite passing is not the same as the software being right, and that gap is where the nasty surprises live.
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 about to promote it, launch it, or raise on it
- Reports have started disagreeing with each other
You are probably fine if
- You are the only person who uses it
- It holds nothing you would mind losing or leaking
- It is still a prototype and everyone treats it as one
- It is a throwaway you will rewrite when the idea is proven
Questions about auditing an Emergent app
The code, which Emergent syncs to a GitHub repository you control, and ideally read-only access to the database so we can look at what is actually in the collections rather than only what the code expects to be there. We do not need access to your Emergent account, and we will not change anything in your application.
It is a good start, and it is more than most generators give you. The limitation is that a test written by the same process that wrote the code describes what the code does, not what your business needs it to do. If a calculation is wrong, the test will assert the wrong answer and pass happily. Part of what the audit does is read the tests as claims about the system and check whether those claims are the right ones.
Not necessarily, and we will not tell you to migrate for the sake of it. MongoDB is a perfectly good database and there are applications it suits well. The question is whether your data has relationships and consistency requirements that the application is now responsible for enforcing on its own, and whether it is actually doing that. Sometimes the answer is to add the missing checks and indexes. Occasionally the shape of the business really does call for a relational database, and we will explain why rather than asserting it.
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 Emergent expertise, it is that Emergent produces React, Python, FastAPI and MongoDB, which is what we have been building and fixing for years.
Yes, and that is often what happens next. Because Emergent produces standard code in a repository you own, there is nothing stopping a development team picking it up. The audit is the sensible first step either way: it tells you what state the foundation is in before you decide whether to build on it, repair it, or replace part of it.
Built with something else?
We audit what these tools produce, whichever one you used.
Other AI app builders
- Lovable app audit
- Replit app audit
- UI Bakery app audit
- Bolt app audit
- v0 app audit
- Base44 app audit
- Firebase Studio app audit
- Databutton app audit
- Rork app audit
- a0.dev app audit
- FlutterFlow app audit
- Bubble app audit
- Glide app audit
- Softr app audit
- Adalo app audit
- Retool app audit
- Appsmith app audit
- Budibase app audit
- ToolJet app audit
- Xano app audit
- Airtable app audit
The audit
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 API endpoint
- Database structure and whether your data can be trusted
- Whether it will hold up as usage grows
- Whether it can be maintained and changed safely
We reply within one working day.
