Built with AI. Checked by an engineer.
For founders, product managers and designers who built an iOS app with AI and need to know what is really under the hood before they build more, launch, or scale. I've built native iOS for fourteen years, and I use AI to write code every day, so I know where it cuts corners.
Problems in AI-built code are cheap to find early and expensive to find in production.
The moment before it gets expensive.
Before you build more.
Every new feature lands on what is already there. Find out whether the foundation will hold it, or whether each prompt is quietly making the app more fragile.
Before real users.
Exposed API keys, open data and unprotected accounts are easy for AI tools to get wrong and expensive to discover after launch. Check them before launch, along with anything that would get the app rejected by Apple.
Before you scale.
What works for ten users can fall over, or run up a surprising bill, at ten thousand. Know where the limits are before your users find them.
When you're stuck.
The AI goes in circles, fixes one thing and breaks two, and you can't push it any further. Find out why, and what it actually takes to move forward.
The parts of an app you can't see from the screen, and the ones AI tools most often skip.
Everything under the hood.
Security
API keys and secrets shipped inside the app, who can read and write your data, how sign-in works, and whether anything sensitive is exposed. Keys belong on a server or in a secret manager, never in the app.
Architecture
Whether the code is organized to grow, or tangled so that every change risks breaking something else. Duplicated logic, dead code, and the shortcuts that compound with every prompt.
Stability and performance
Crashes, threading and race conditions, memory, and how the app behaves on a bad connection. The bugs that never show up in a demo and always show up with real users.
Backend and cost
How the app talks to Firebase, Google Cloud or whatever sits behind it, whether server logic lives in the right place, and what the bill looks like as usage grows.
App Store readiness
Review guidelines, privacy disclosures, subscriptions and in-app purchases. The reasons apps get rejected, found before Apple finds them.
The way forward
What to keep, what to fix, what to rebuild, and in what order. Sometimes the honest answer is that it's in good shape, and then the report says so.
Not a sales pitch with a document stapled on. A diagnosis that stands on its own.
A straight answer, in writing.
A written report in plain language, built for someone who doesn't read code. Every finding is ranked by risk and says what it costs to ignore and what it takes to fix.
Then we get on a call and I walk you through it, so you can ask anything and leave knowing exactly where you stand.
- 01A written report, ranked by risk
- 02A walkthrough call
- 03A clear path: keep, fix, or rebuild
- 04Yours to keep, and to hand to any developer
The difference between an app that demos well and one that holds up is someone who reads the code.
I use AI too. I read every line.
AI writes a lot of my code now. The difference is that I review every diff, every time, and slow down whenever something could come back to bite me. Fourteen years of native iOS decide what ships, not the model.
I've taken over a codebase an overseas team gave up on and landed it in production. I've also taken over a sprawling app overgrown with AI-generated code, cut through the bloat to fix what was broken, and simplified how it works.
I also built the secure proxy server behind one of the first LLM apps on the App Store, and a real-time AI hearing app for Martin Cooper, the inventor of the cell phone.
"He is a mature senior software engineer who is open minded, goes deep to ensure the design and implementation are the right ones."
What people ask before handing over an app they built themselves.
Straight answers.
Do I need to know how to code?
No. The report is written for someone who has never read a line of code. Anything technical comes with what it means for your app, your users and your budget.
What can you audit?
Native iOS apps built in Swift, whichever AI tool wrote them, and the backend behind them: Firebase, Google Cloud, or a similar service.
What do you need from me?
Access to the code and to the backend the app runs on, plus a short conversation about what the app is for and what you want to do next. That tells me where to look hardest.
What if it turns out to be a mess?
Then you find out now, while it is cheap, and the report tells you what is worth keeping. AI-built code is rarely all bad. The job is to separate the parts that will hold from the parts that will not.
Can you fix what you find?
Yes, if you want me to, scoped from the report's findings. There is no obligation. The report is yours, and it is written so any developer can pick it up and act on it.
How much does it cost?
It is a fixed price, quoted once I have a short look at what you have built, so you know the full cost before anything starts.
Know what you've built.
Tell me what the app does, what you built it with, and what you want to do next. I'll tell you honestly whether an audit is the right step.