CreidenLoading content, please wait

AI wrote the code, nobody reviewed it

Your AI-built app has problems nobody has looked for

Those problems put your users, your data and your business at risk. Our engineers bring human eyes to what AI misses: logins, data, security, and how changes reach your users. In 5 days you get a written report of what to fix first.

Read-only access, revoked when the audit closes. We'll sign an NDA first if you want one.

Production Readiness Report
  • Live database credentials on the main branchCritical
  • No staging. Every fix goes straight to those 28 usersHigh
  • The app works. 28 people use it dailyOK
  • Live code that was never committed to the repositoryCritical
  • No password reset, no second factor at loginHigh
  • One file, 7,500 linesMedium
Two of these could not wait
From a real audit of a Lovable build. Found by engineers reading the code.

Symptom check

Vibe-coded app problems

It looks good in a demo. Then real people start using it. Things break, someone gets stuck, workarounds pile up. None of that means the product is bad. It means it was built to show the idea, not to work for the people now depending on it.

Nobody knows what a change will break

You ask for one small fix and something unrelated stops working. You find out when a user tells you.

Nobody knows where your data lives

The platform set the database up for you. Nobody is certain whose account it sits in, or who could get a copy out if you needed one tomorrow.

A customer is asking questions you cannot answer

Uptime, access control, where their data sits. The questions are reasonable and you have nobody to hand them to.

The code is not really yours

It lives inside a platform account. You can look at it, but you cannot take it anywhere.

Your users find the bugs first

Every fix goes straight to the version your users are on, with no test copy in between. They are your testing environment.

No one senior to ask

Nobody in house can review the architecture, catch a bad call before it is built, or own the technical decisions you are being asked to make.

A real audit

What a production readiness audit finds in a Lovable app

A non-technical team built an internal ERP on Lovable. It looked finished and it ran the business. We were asked to look under it before the company grew any further.

Platform it was built on
Lovable
Employees using it daily
28+
Senior engineers reading the whole build
5 days

Some of what we found

  • CriticalLive database credentials committed to the main branch
  • CriticalProduction code that was never committed to the repository
  • HighNo password reset, and no second step at login
  • HighFeatures that only saved data on the user's own computer, so it vanished on another device
  • HighNo staging environment and no deployment workflow
  • MediumTwo separate login screens
  • MediumA single file of 7,500 lines

How it works

Five days, one report

Senior engineers read your build by hand. This is a review, not a penetration test: we read code, configuration and access with read-only credentials, and we never attack your running app. Fixed scope, no discovery phase to pay for. You keep working while we do this.

  1. Day 1

    Access and inventory

    We take read access to the repository, the platform account and the database, then map what actually exists against what you believe exists. Differences at this stage are normal and usually the most useful finding of the week.

  2. Day 2

    Security and data

    Secrets, credentials exposed in the browser bundle, database access rules, and what data is held where. We check what is reachable without logging in at all.

  3. Day 3

    Authentication and access

    Every route into the application, the account recovery path, and the boundaries between one customer's data and another's.

  4. Day 4

    Deployment and recovery

    The path from a change to your live users, the absence or presence of a staging step, backup coverage, and a real restore test where one is possible.

  5. Day 5

    Code health and write-up

    Structure, duplication and the parts that will break under growth, then the report itself, one you can read without an engineer in the room.

  6. Deliverable

    What you receive

    A written report from the engineers who read your code, in plain language, prioritised by what will cause problems first. The easy fixes are rarely the urgent ones. Every finding states the risk, the effort to resolve it, and what happens if it is left alone. It is yours to act on with us, with your own team, or with anyone else.

Working together

3 ways to fix an AI build

Each one is scoped before you commit to it. Everyone starts with the audit, and what follows is priced from what we find, not from a guess made before it.

Treatment

Scoped from the audit

Fixed price, agreed before we start

We fix what we found, in the order the report sets out, with a price agreed before the work starts.

  • Scope and price drawn directly from the audit findings
  • Your code moved into your own repository and accounts
  • Staging, deployment and backup put in place
  • Handover notes your team can work from

Fractional Tech Lead

Monthly retainer

Scoped from the audit

A dedicated senior engineer accountable for your technical decisions while you are too small to hire one full time.

  • A dedicated senior engineer, agreed days per month, not a rotating pool
  • Architecture and hiring decisions reviewed before they are made
  • Code review for whoever is building, in house or AI assisted
  • Cancellable, with the work documented as it goes

The audit is a fixed price, agreed before it starts, with nothing added to it. You get the figure on the call, once we know what your build is. Treatment and retainer pricing is quoted only after the audit, because pricing either one earlier would be a guess.

Fit

Who an AI build audit is for

This is for you if

The product is real and the risk is already live.

  • You have a live product with users or revenue depending on it
  • It was built on Lovable, Bolt, Replit, Cursor, Base44 or something similar
  • There is no senior engineer in house
  • Customers, investors or auditors have started asking technical questions

This is not for you if

We would rather say so now.

  • You have a prototype with no users yet
  • You are looking for the cheapest possible rebuild
  • You already have a senior engineer leading the work
  • You cannot give read access to the code and the database

Free check

Check your build yourself

Fifteen questions covering what only starts to matter once real people are using the app: who can see whose data, what happens when something fails, and whether anyone can put it back. Scored as you go, with the result on screen at the end. It grades what you tell us. The audit grades what we find in the code.

Start the build check

Two minutes, free, no email needed. Shorter than the full checklist, and no substitute for the audit.

PreviewProduction readiness check
  • 01Is your source code in a repository your company owns, not only inside the platform account?
  • 02Are you certain nobody using your app can read your keys or passwords?
  • 03If someone who is not logged in pastes the address of a private page, are they reliably stopped?
  • 04Has anyone ever restored the database from a backup and confirmed it worked?
  • 05When you ask for a change, does anyone know what else it might break?

Why Creiden

We built production systems before AI wrote any

Building and running software
15 years
Projects delivered
400+
Countries served
15+
Delivery in both languages
AR and EN
Teams we have built for
ABA logo
ESTBRQ logo
Flipout logo
In & Out logo
Ithaka logo
Kiinde logo
micharity logo
MLA+ logo
Next Generation Schools logo
OPPO logo
Tamara logo
Warner Bros. logo
UBA logo
Unique Vision logo
Webook logo
ABA logo
ESTBRQ logo
Flipout logo
In & Out logo
Ithaka logo
Kiinde logo
micharity logo
MLA+ logo
Next Generation Schools logo
OPPO logo
Tamara logo
Warner Bros. logo
UBA logo
Unique Vision logo
Webook logo

Questions

Questions about fixing an AI build

Usually not. Most AI built apps are worth keeping. What is missing is the engineering around them: version control, a staging environment, real authentication, backups and a sane file structure. We recommend a rebuild only when repair costs more than replacement, and the report shows that arithmetic.

Yes. These are legitimate tools and we work alongside them, so this is not a matter of leaving one. The code moves into a repository your company owns, the database into an account under your control, and deployment onto infrastructure you can see. Scope and price come from the audit.

Lovable connects to GitHub from the project settings, which pushes the code into a repository you own. The export itself is the easy part. What it does not carry across is your database, your secrets, or a safe way to deploy a change, which is where most founders get stuck.

It can be, but it usually has not been checked. The gaps we see repeatedly: API keys shipped in the browser bundle where anyone who opens the app can read them, row-level security left off on the tables the platform created, and no password reset or second step at login. None are hard to fix once found, but they stay invisible until somebody looks.

Less often than people assume. The platform provisions the database for you, so it sits in an account you pay for but never set up. Getting a clean export out of it, or moving the code into a repository your company controls, is harder than it should be.

The audit is a fixed price covering 5 days of work and a written report, with nothing added to it. We give you the figure on the call, once we have heard what your build is and confirmed the audit is worth doing at all. Treatment and retainer pricing is quoted only after the audit, because pricing repair work before reading the code would be a guess.

Yes. The report is written to be handed on: every finding states the risk, the effort to resolve it, and what happens if it is left alone. Investors and acquirers test for the same things we do. Most founders order it before a raise rather than after a term sheet arrives.

Often yes, up to a point. The usual limit is not raw traffic but everything around it: no caching, queries written without indexes, state held in the browser, and no way to deploy a fix safely while users are on the app. All of it is fixable.

Yes. The audit reads your repository, your platform account and your running application, so the tool that generated the code matters less than what it produced. We see builds from every one of these generators, and the failure patterns are consistent whichever tool wrote it.

Yes. Access is read-only unless you ask otherwise, it is revoked when the audit closes, and findings are never named or shown in our own material without written permission. We will sign your NDA if you want one in place first, or provide ours.

Next step

Find out what your app is carrying, before your users do

A short call to see whether the audit is worth doing. If it is not, we will say so on the call.