The review after the code review, for software built with AI
Claude can review the code. Before colleagues, customers or money depend on what you built, I check what a code review does not: what the app does to the business, what it costs at real usage, and what stops it when something goes wrong. $1,499, report within five business days.
Claude Code, Cursor, Lovable and Replit made it possible to build real software without a development team, and a lot of what gets built this way is good. Ask Claude to review the code and it does that well too: it fixes what it finds and does what it is told. What it does not do is think about what nobody told it to. That worry tends to arrive right before you hand the app to someone else: a colleague, a customer, the whole office. What happens to the business when the app does exactly what it was built to do, a thousand times a day? What does the bill look like once real people use it? What stops it when something goes wrong, if the AI or the code does not?
Build to Prod is that zoomed-out review. It starts where the code review stops, before people depend on the app.
You work with me, start to finish
Not an agency, and not a team your app gets handed around. I do the inspection, I write the report, and I am the person you call when something in it is unclear or when the app changes and you want to know whether a finding still applies. By the end I know your app, what it is for and what is riding on it, so you never have to explain it twice.
I have been building and shipping software since 2010, more than 100 apps, and I have kept my own running through years of updates. I know what tends to break after launch, when nobody is watching.
What I check
The checks are chosen for your app, from what it does and what it touches. A scheduling tool for twelve staff and a customer portal that takes payments do not fail the same way, so they do not get the same checklist. Most of the work is on the business around the code.
- What an agent may do. For an AI agent or automation connected to email, customer records, accounts or payments: what it can do without a person approving, what it can do that nobody intended, how far one wrong action spreads before anyone notices, and who can cut off its access in a minute.
- What it does to the business. What happens to customers, staff and the books when the app works exactly as built: an automation that emails every customer, a sync that overwrites a record someone relied on, a total the accountant now trusts that rounds differently.
- What changes around it. The manual check nobody does anymore because the app does it, and the process that now runs only through the app.
- The bill. How AI and API spend grows with real usage, not only on the day you tested it, and whether your spending limit actually stops anything or only sends an email.
- Guardrails outside the model. Caps, approvals, rate limits and a way to switch it off that hold even when the AI or the code misbehaves, and a person who gets told when they trip.
- Bad days. What happens when the payment provider, the database or the AI service is slow or down, and whether a double click charges a customer twice.
- Backups. Whether they exist, and whether they restore.
- Who owns it. Whether the company, not one person, controls the code, the hosting, the domain and the logins.
- The security baseline. Whether one user can reach another’s records, where the keys and logins are, and whether someone can skip a step the process depends on. A good code review covers much of this, so I verify it rather than start from it.
I use professional scanners and AI tools where they save time, and I verify every important finding myself before it goes in the report. With your permission I test the running app as well as the code, because the code alone cannot tell you how the live system is set up.
Hardening, not rebuilding
Very little of what I see needs to be thrown away. Most AI-built apps need tightening: a key moved out of the code, a check on who can open a record, a hard cap on a bill. The report says what to keep as it is, what to harden, and, in the rare case it is warranted, what to replace and why.
What you get
Within 48 hoursA call. I learn how the business uses the app, who depends on it and what a bad day would cost, and you can ask me anything.
Within five business daysThe report. A plain-English summary of where the app stands and what should hold up a launch, then each finding with its evidence, what it could mean for the business, and the fix.
Fix instructions you can useWritten precisely enough to paste into Claude Code or Cursor, or to hand to a developer, each with a test that shows the fix worked.
A walkthroughWe go through the report together until every finding makes sense to you.
One retestWhen the fixes are in, I check them again.
$1,499, fixed. No hourly meter, no surprise invoice.
Credited in full to an engagement you start within 30 days, if the report raises a bigger decision you want help with. There is no obligation to start one.
The standards behind the checks
What I check draws on the standards application security professionals use:
- OWASP Application Security Verification Standard (ASVS)
- OWASP Top 10
- OWASP API Security Top 10
- OWASP Top 10 for LLM Applications, when the app uses AI
- OWASP Mobile Application Security (MASVS), for iPhone and Android apps
- NIST Secure Software Development Framework (SSDF, SP 800-218)
These standards shape the inspection. It is not a certification, a formal penetration test or a compliance opinion, and it does not replace one when a contract or a regulator requires it. For an attacker’s view of an established production system, see the Production Security Assessment.
Start with a message
A couple of lines is enough: what you built, who uses it, and what worries you. I read every message myself and reply within a day.
Please do not send passwords or keys. If I need access, we agree how first.
Frequently asked questions
- Can’t I just ask Claude to check it?
- You should, and I use it too. Claude is a very good coder and does what it is told, so let it review the code first. This comes after. Claude skips checks nobody asked for and reports what it missed with the same confidence as everything else. It cannot see the business around the code: which data would hurt to lose, which rule your accountant relies on, what the bill does at ten times the usage, what has to be fixed now and what can wait. And it builds eagerly. Two weeks of asking for one more feature leaves you with a stack of pancakes, each layer piled on the last, instead of a plate where everything has its place. Telling those apart takes someone who has shipped and maintained software for years.
- Who will I actually work with?
- Me. I do the call, the inspection, the report, the walkthrough and the retest. There is no account manager and no team your app gets passed around. When you call with a question, you reach the person who read your code.
- Does it have to be built with AI?
- No. An app a freelancer or an agency built for you gets the same inspection, and the best time for it is before you accept the delivery.
- Does this cover an AI agent or an automation?
- Yes, whether it was built or only configured. An agent or automation about to get access to email, customer records, accounts or payments, and to act without a person approving each step, gets the same inspection. The focus is what it is permitted to do, how far one wrong action spreads, and who can switch it off.
- It is only an internal tool. Does this apply?
- Often more than to a public app. A tool your staff built that touches payroll, accounting or customer records can do more damage than a website, and it usually gets less attention.
- What access do you need?
- Usually read access to the code and a call. For a live app I may ask for a test account or a copy to test against. I do not need production passwords by default, and I tell you exactly what I need before anything is shared. Please do not send passwords or keys through the contact form.
- Will you tell me the app is safe?
- I will tell you what I checked, what I found and what I could not verify. No honest inspection can promise that an app is safe, so mine does not.