Why this exists
The interface finishes before the engineering does
AI tools take you from idea to working application in days. That part is real.
What they don't produce is the judgement underneath — whether the architecture will hold, whether data is protected, whether another engineer could take it over, whether the thing works when something goes wrong.
None of that is visible from the interface. An app can look complete, demo perfectly, and still be an unsound foundation for the next six months of work. The only way to know is for someone to read it.
The question worth asking isn't what to build next. It's what you've already built, and whether it holds.
What an audit answers
The three questions
A code review looks at implementation details. This looks at the system.
Question | What it covers | |
01 | Does it work? | Broken workflows, incomplete features, failing integrations, and the paths nobody tested. |
02 | Is it engineered properly? | Architecture, security, data handling, dependencies, and whether it can be maintained by someone who didn't write it. |
03 | Can it become a real product? | The distance between what exists and what production actually requires. |
A prototype can pass the first and fail the other two. That's the normal result, and it's not a failure — it's the information you need before deciding what happens next.
Scope
What we read
Area | What we look at |
Architecture | Where logic lives, how layers separate, whether new features can be added without coupling everything together. |
Security | Access control, exposed secrets, authentication, data exposure, client-server boundaries. |
Data layer | Schema, relationships, constraints, query patterns, migrations, and whether the model holds at scale. |
Integrations | Third-party APIs, webhooks, error handling, and what happens when an external service fails. |
Code quality | Duplication, complexity, dead code, competing patterns, and how hard it is to change safely. |
Dependencies | Versions, known vulnerabilities, unmaintained packages, and things pulled in that aren't used. |
Testing | What's covered, what isn't, and which critical workflows have nothing protecting them. |
Deployment | Environment configuration, build process, staging separation, and whether releases are repeatable. |
Observability | Whether you'd know something had broken before a customer told you. |
Performance | Query patterns, request volume and rendering behaviour that work now and won't at scale. |
The decision
Keep, fix, refactor, replace, rebuild
The most common mistake with an AI-built codebase is treating it as one thing. It isn't — different parts are in different condition, and the right call differs for each.
Verdict | Meaning |
Keep | Working and sound. Leave it alone. This is usually most of the codebase. |
Fix | Working, with an identifiable problem. Cheapest category to address. |
Refactor | Works, but can't be safely extended in its current shape. |
Replace | The current implementation carries risk that isn't worth carrying. |
Rebuild | Not a practical foundation for what comes next. Rare, and we say why. |
Most audits return mostly Keep. The product logic is usually sound; the problems sit in the layer underneath. An audit that recommends rebuilding everything should be read sceptically, including one of ours — ask for the reasoning about the data model specifically.
Readiness
Where you are now
Stage | What it means |
Prototype ready | The idea can be demonstrated. It works when you drive it. |
MVP ready | A controlled group of real users can use it without something going badly wrong. |
Production ready | Security, reliability, testing and operational controls appropriate for people who don't know you. |
The audit places you on this ladder and names what stands between you and the next rung. That's usually a shorter list than people expect.
The deliverable
What you get
Findings. Each one with the file it lives in, what it means in practice, what it could cause, and what the fix is. Ranked critical, high, medium, low — by consequence, not by tidiness.
Architecture note. How the system is actually structured, where the weak joints are, and which decisions will become constraints as usage grows.
Verdict map. Every significant component marked keep, fix, refactor, replace or rebuild, with the reasoning.
Production gap list. What specifically stands between this and real users.
A sequenced roadmap. Not thirty disconnected findings — an order of work:
Fix → Harden → Refactor → Test → Deploy → Operate
Phase | What it addresses |
1. Critical fixes | Security, data integrity, auth and anything that fails in production. |
2. Stabilisation | Broken workflows, error handling, integration reliability. |
3. Engineering | Refactoring, architecture, technical debt, maintainable patterns. |
4. Production prep | Testing, configuration, observability, deployment. |
5. Continued development | Features, on a foundation you can now reason about. |
The report is written to be useful to whoever does the work — your team, a new hire, or us.
Timing
When to audit
Situation | Why now |
Before hiring developers | Know what the codebase needs before you interview for it. It also halves onboarding time. |
Before adding major features | Building on a weak foundation costs more than fixing the foundation. |
Before launching publicly | Production gaps are cheaper to find than to discover. |
Before raising | Technical due diligence looks at exactly this. Better to see it first. |
Before handing over | A takeover needs a baseline, whoever is taking it. |
After a failed attempt | Understanding why the last approach stalled is usually more useful than starting again. |
After rapid AI development | Establishing the condition of generated code before more accumulates on top. |
When something feels wrong | Vague unease about a codebase is usually correct and rarely specific. |
Who this is for
Founders | You built it with AI and need to know whether it can become a real product. |
Non-technical founders | You need someone to explain what's working, what's risky, and what it costs — in language you can act on. |
Startup teams | An independent view before committing the next quarter of engineering. |
Agencies | You've been handed an AI-built application and need a baseline before taking ownership. |
Product teams | You inherited a codebase and need to understand it before expanding it. |
Investors | Someone else's AI-built product, and a decision to make about it. |
What this isn't
Not a penetration test.
This is a code and configuration review, which finds more in AI-built apps because the problems are usually in what was never written. If you need a formal pentest for a compliance requirement, we'll say so.
Not a compliance certification.
We can produce something suitable for a customer's security questionnaire and a remediation record. SOC 2 or ISO is a separate, longer process.
Not a scanner.
Automated tools check whether protections are enabled. They can't tell you whether a policy is correct or whether the application bypasses it — the two most common causes of a leak.
Not a sales exercise.
Roughly a third of the time the honest answer is smaller than people fear. You'll get that answer too.
The process
How it runs
Step | What happens | |
01 | Free triage | Send the repository. Within 48 hours you get a written summary of what's wrong and what a full audit would cover. No charge. |
02 | Scope | If a deep audit makes sense, a fixed scope and price. If it doesn't, we'll say so. |
03 | Read | An engineer reads the codebase, the configuration and the deployment across every area above. |
04 | Assess | Findings ranked, architecture documented, verdicts assigned per component. |
05 | Report | The deliverable, plus a call with the engineer who wrote it if you want one. |
06 | Optional | We do the work, your team does it, or a new hire does it. All three are normal. |
What we need
What you send | Why |
Source repository | The core of it. Read access is enough. |
Deployed application | Production behaves differently from development. |
Database access or schema | The data model is the single strongest signal of whether something is worth keeping. |
Environment configuration | Where a surprising share of production problems live. |
Known issues | Your side of the story. Saves us finding what you already know. |
What it's meant to do | Product context. Helpful, not required. |
Not every item is needed for every audit. If you're missing some, send what you have.
Questions
Question | Answer |
How is this different from the free audit? | The free triage tells you whether something is wrong and roughly where. This reads the whole system and tells you what to do about it, in what order. Start with the free one. |
Can you audit a Lovable, Bolt, Replit or Cursor app? | Yes, and any other AI-assisted workflow. What matters is the condition of the application, not which tool produced it. |
Will you recommend a rebuild? | Only if it's genuinely the answer, and only with reasoning about the data model specifically. Most audits return mostly Keep. |
Can you audit a prototype? | Yes, and it's often the cheapest time to do it — before more is built on top of a decision that will have to be undone. |
Do you fix what you find? | If you want. The report is written to be actionable by anyone, including your own team or a new hire. |
How long does it take? | The free triage is 48 hours. A full audit is typically three to ten working days depending on size — we give you a date when we scope it, not a range. |
Do you do penetration testing? | Not as part of this. If you need one, we'll tell you and help define the scope. |
Who reads my code? | One senior engineer. Never used for training, access removed after delivery. Mutual NDA before you send anything. |
What happens to my code? | Nothing. An audit reads; it doesn't modify anything. Any engineering work is a separate agreement. |
First step
Start with the free triage
Send the repository. Within 48 hours you'll get a written summary of what's wrong, what's urgent, and whether a full audit would tell you anything you don't already know.
If it wouldn't, we'll say so.
No charge. No obligation. Reply within 48 hours.
Also relevant
Security audit · Codebase takeover · Production readiness · Refactoring · Stuck at 80%