Your AI-built app has real users now.
Built with Lovable, Replit, Bolt, Cursor or Claude Code? I close the security gaps, make deployments safe and reversible, add monitoring and tests, and get it ready for a security review or a traffic spike. Without a rewrite.
Something forced the issue.
- A customer sent a security questionnaire. Forty questions about encryption, access control, incident response and data retention. The deal is waiting on answers you don't have.
- Due diligence is coming. Your investors are bringing in someone technical to look at what you built. You'd like that to go well.
- You've had an outage. It came back, you're not sure why it went down, and you have no confidence it won't happen again.
- Traffic is growing. What handled two hundred users is visibly straining at two thousand, and twenty thousand is on the roadmap.
- You're about to launch. Fixed date, real marketing spend behind it, one chance at a first impression.
If none of these have happened yet, you probably don't need this yet. When one does, the clock is usually short — which is why the work is scoped in weeks rather than months.
Nine things that are true of most AI-built apps.
Not hypotheticals. These are the findings that come up again and again, and most of them you can check yourself in an afternoon. If you recognise three or more, the review will pay for itself.
- API keys sitting in the browser. Open your live site, view source, and search for your Stripe, OpenAI or database keys. If they're there, anyone can read them, and anyone can spend your money with them.
- Database rules left permissive. Supabase and Firebase ship with open rules so that your app works on day one. If nobody tightened them, any user can read every other user's rows — including the ones with addresses and payment details in.
- No rate limiting on public endpoints. Your signup, login and password-reset routes accept as many requests a second as anyone cares to send. That's how you get credential stuffing, a five-figure AI bill, or an outage caused by one person with a script.
- Payment webhooks accepted without signature verification. Stripe signs every webhook it sends so you can prove it came from Stripe. If you don't check that signature, anyone who guesses the URL can tell your app a payment succeeded. It will believe them.
- Secrets committed to the repository. Deleting a key from a file doesn't remove it from git history. It's still there, in every clone, forever, and scanners find public repos within minutes of a push.
- No backups, or backups nobody has restored. A backup you have never restored is a belief, not a backup. The time to find out whether it works is not the morning you need it.
- No error monitoring. If nothing reports errors to you, then every failure is invisible until a user complains — and most users don't complain, they leave. You are almost certainly losing signups to a bug you don't know about.
- Auth that checks the UI but not the API. The admin button is hidden from ordinary users, but the endpoint behind it never asks who is calling. Hiding a door is not the same as locking it, and the API is a door.
- No staging environment. Every change goes straight to production, tested by your customers. One bad deploy on a Friday and there's no tested way back.
There's a longer, plainer version of this you can work through yourself: ten things to check in your AI-built app before you take payments. Free, no email address required.
What actually gets fixed.
- Security. Secrets moved out of the codebase into proper management. Authentication and authorization checked on every route, not just the ones that were remembered. Rate limiting, input validation, dependency vulnerabilities, production access locked down and logged.
- Data. Backups that exist and have been restored at least once, because an untested backup is not a backup. Proper migrations. Query and index review, so one slow page can't take everything else with it.
- Payments and sensitive data. Idempotency, so a retry doesn't charge twice. Webhook verification. Audit trails. Card and personal data kept out of systems that shouldn't hold it. Built on direct experience with PCI-DSS integrations across Stripe, PayPal, Worldpay, PayU and CCAvenue.
- Deployment. An automated pipeline. Releases that don't take the site down. A rollback that has been tested before you need it. A staging environment that resembles production closely enough to be worth having.
- Monitoring. Alerts that reach a human, error tracking, and enough visibility that you learn about problems before your customers do.
- Infrastructure and cost. Right-sized and scaled sensibly. On one financial platform re-architecture, monthly infrastructure cost fell by roughly 76%.
- Tests where they matter. Not full coverage — that's the wrong goal here. Tests around the paths that would hurt most if they broke: payments, authentication, data integrity. Enough that the next change stops feeling like a gamble.
How it runs.
Technical review — $500
A few days. Full assessment of the codebase, infrastructure and deployment setup. You get a written report, a prioritized risk list, a remediation plan with real estimates, and a walkthrough call. You can stop here, and some people do.
Scoping
We agree exactly what is in and what is out, at a fixed price with a fixed date. No open-ended hourly work.
The work — three to six weeks
Highest-risk items first, so value lands early even if you pause partway. Weekly written updates. Everything goes into your repository as it happens through pull requests you can read.
Handover
Documentation, runbooks and a walkthrough, so whoever works on it next isn't guessing. Ongoing cover is a separate monthly arrangement — offered, never assumed.
What you're left with
- A written record of what was wrong and what was done — usable with customers and investors, not just engineers
- Deployments you can run without holding your breath
- Monitoring that tells you before your users do
- Answers to the security questionnaire
- A codebase your next developer can work in
What this isn't
- No new feature work during a stabilization engagement — mixing the two is how both go badly
- No rewriting working systems for aesthetic reasons
- No engagements for apps with no users yet; there's nothing to stabilize
Start small, decide later.
| Stage | Price |
|---|---|
| Technical review Fixed price, no commitment. Credited against the work that follows if you proceed within 30 days. | $500 |
| Critical fixes only Just the highest-severity findings from the review, remediated at a fixed price. Nothing else touched. For when a handful of things are genuinely dangerous and the rest can wait until they matter. | from $1,500 |
| Full stabilization Final price shared after the review, set by scope and complexity once the real state of things is known. Security, data, deployment, monitoring and tests where they matter. | from $4,500 |
If the review only turns up a couple of small problems, I’ll fix them as part of the $500 rather than quoting you for an engagement you don’t need. An audit that always concludes you need an audit-shaped amount of work isn’t an audit. Some people take the report, sleep better, and never come back — that’s a good outcome.
Milestone payments are available instead of 50% upfront. After the first milestone, if you’re not satisfied, you can stop and have that payment refunded. If the work overruns against the scope we agreed, I absorb it — the price you were quoted is the price you pay.
Before you book.
Why can't I just ask an AI to audit it?
You can, and you should — it will find real things. The problem is what comes back: sixty findings with severity labels and no way for you to tell which three will actually take you down and which fifty-seven are noise. Knowing what not to fix is most of the value, and AI tools are poor at it because they're rewarded for finding things. There's also the part no tool provides: a senior engineer putting their name on "this will hold, and here's what breaks first" — which is what an investor or an enterprise customer is actually asking for.
Will you tell me I have to rewrite everything?
Almost certainly not. Rewrites are usually the wrong answer and always the expensive one. Most of what gets found is fixable in place. If something genuinely does need rebuilding, you'll be told why in terms of what it costs you not to.
What if I don't like the findings?
You still own the report and the plan, and you're under no obligation to hire me for the fix. That's precisely why the review is priced separately.
When should I not pay for this?
If nobody is using the app yet and no money moves through it, don't. The risks here are real only once there's something to lose — go and find out whether anyone wants the product first. If you already have a competent engineer on it, they'll do this better than I will, because they know the codebase and I'd spend your first week reading it. And if you're hoping a report will win an argument with a developer you've stopped trusting, that's a conversation, not an engagement.
How much of my time does this take?
About an hour at kickoff, a short weekly check-in, and access to your systems. The point is that you keep running your business.
Do I have to stop shipping while you work?
No, but coordinate on anything touching the same areas. You'll be told which files to stay out of.
What if you find something catastrophic?
You hear about it the same day, not in week four. If it changes the scope, we re-scope before spending your money.
Find out what you're actually sitting on.
Twenty minutes, no pitch. Describe what you've built and what's worrying you, and you'll get a straight answer on whether it's a problem worth spending money on.