You Built It with AI. Now Let's Ship It Properly.
Vibe coding is a legitimate way to build. The problem isn't the AI — it's that the AI only builds what you ask for. Security configurations, authentication edge cases, secrets management, and production infrastructure all require someone who knows to ask for them in the first place. That's where we come in.
The Gaps Your AI Builder Left Behind
Not because the AI is bad at code. Because you cannot ask for what you don't know to ask for.
Security Nobody Asked About
Rate limiting, session invalidation, CSRF protection, SQL injection guards — these don't appear in vibe-coded apps because most founders never think to mention them. They're invisible until the moment they become catastrophically relevant.
Structural Debt That Compounds
AI tends to put everything in one place. No separation of concerns, no consistent error handling, no database migration strategy. It works fine at 50 users. At 5,000, something breaks — and figuring out why takes longer than it should.
Production Blindspots
Credentials committed to version history. Stack traces rendering directly in the browser. No staging environment. No observability. Your app is live and something has been wrong for weeks — you just don't have the logging to know it yet.
Two Ways We Can Help
Depending on how involved you need us to be.
Tier 1 — Production Readiness Audit
We review your codebase and deliver a structured, evidence-based report. You decide what to do with it — hand it to your own developer, act on it yourself, or come back to us for remediation.
- Full security vulnerability assessment
- Authentication & session management review
- Secrets and credentials exposure check
- Database schema and indexing analysis
- Dependency audit against known CVEs
- Environment and deployment readiness check
- Findings prioritised: critical / important / minor
- Concrete remediation recommendation for every issue
Tier 2 — Full Remediation & Hardening
We fix everything. Our senior engineers go through the codebase systematically, resolve every critical and important finding, and hand back an application that's genuinely ready for real users at scale.
- Everything in the Audit, plus
- Hands-on remediation of all critical and important findings
- Proper authentication flow implemented where required
- Secrets moved out of the codebase into managed configuration
- Database schema and indexing corrected
- Structured error handling and logging added
- Staging environment established
- Documented, repeatable deployment process handed over
What We Actually Look At
Not a generic checklist from a template. A structured review by engineers who've opened real vibe-coded codebases — including one that was serving 500 live users with no security layer, no staging environment, and API keys in plain text.
- Authentication: Token expiry, session invalidation, rate limiting, brute force protection, and whether your "logged in" check can actually be bypassed.
- Input Handling: Every place user input touches your system — SQL injection, XSS, CSRF, and anything that lets someone feed your application data it wasn't expecting.
- Secrets Management: API keys, database credentials, third-party tokens — where they live, whether they've ever been committed to version history, and whether they're scoped correctly.
- Data Layer: Schema design, missing indexes, unguarded N+1 queries — anything that works fine in development and falls over when real data volumes appear.
- Error Handling: What your users see when something breaks, and whether your logs contain enough context to actually diagnose what went wrong.
- Dependencies: Every package audited against the CVE database. Known vulnerabilities in third-party code are one of the most common and most overlooked attack surfaces in AI-generated projects.
- Infrastructure: Environment separation, secrets in configuration, and whether your deployment process can be run by someone other than the person who set it up.
- Observability: Whether you have any meaningful visibility into what your application is actually doing in production, or whether you're flying blind.
What AI Assumed Was Fine vs. What Production Actually Requires
What Your AI Builder Delivered
- Login works if you give it the right password
- API keys stored in a .env file that may or may not be gitignored
- Errors caught somewhere and logged to the console
- Dependencies installed without reviewing what they contain
- Database queries that return the right data on your laptop
- A deployment process that works when you remember the steps
- One environment: wherever it's running right now
What Production Actually Requires
- Rate limiting, account lockout, session expiry, and token rotation
- Secrets management with zero credentials anywhere in version history
- Structured error handling that logs context — not stack traces to the browser
- Dependencies audited against known CVEs before they reach production
- Indexed queries that still perform when you have 50,000 rows instead of 50
- A documented, repeatable deployment process that any engineer can run
- Staging, production, and a way to test changes before real users see them
We've Done Exactly This.
A dental SaaS came to us with over 500 live users, a vibe-coded codebase, and no security or compliance layer whatsoever. No audit had ever been run. Stripe was integrated but fragile. The team had no visibility into what was happening in production and no staging environment to safely test changes.
We stabilised the codebase, rebuilt the Stripe and Meta integrations properly, established a staging pipeline, and achieved MHRA Class I medical device certification — without a single minute of production downtime. Their app now runs a 4.9-star rating across the UK's dental community.
Read the Full Case StudyCommon Questions
What does the audit report actually include?
A structured document covering every finding, ranked by severity: critical, important, and minor. For each issue you get what it is, where it lives in the codebase, why it matters, and a concrete recommendation for fixing it. It's written to be understood by both technical and non-technical stakeholders. If you have a developer, they can work from it directly. If you don't, it tells you exactly what you're hiring someone to fix.
How long does an audit take?
For a typical vibe-coded web application, the audit takes 3 to 5 working days from codebase access to report delivery. More complex applications with multiple services, third-party integrations, or significant data handling may take longer. We scope this precisely during the initial discovery call so there are no surprises.
Do you need access to our production environment?
Not for the audit. We work from a codebase snapshot — a private repository or a zip of the source is sufficient. We do not need database access, production credentials, or any live environment access to complete the review. If you proceed to full remediation, we'll discuss appropriate staging access at that point, and only that point.
Does it matter which AI tool built the app — Cursor, Lovable, Bolt?
No. The tool is entirely irrelevant — what we receive is code, and we review code. Whether it was generated by GPT-4o, Claude, a junior developer, or a combination of all three, the same categories of issues appear and the same remediation process applies. We've found identical authentication gaps in a weekend Bolt project and in a £40,000 agency build. The tool doesn't determine the quality; the review process does.
Can we start with the audit and decide on remediation later?
Yes, and this is often the right call. The audit gives you an objective picture of exactly what you're working with. Some clients take the report and hand it to their own developer. Others look at the findings and realise the scope warrants bringing us in to fix it. Either outcome is completely fine — the audit is a standalone deliverable with no strings attached.
You Don't Have to Guess Whether Your App Is Safe.
Book a short discovery call. We'll look at what you've built, tell you honestly what we see, and scope an audit or remediation that fits your situation.