Request a review
Software readiness review for MVPs and AI-built apps
Send me your repo. I read it the way your next developer would, then send you a written report: what's solid, what's fragile, and what I'd fix before you launch, hand it over, or build anything else on top of it.
No call required. Async by default.
The problem
A demo that works can hide a lot: setup steps that only exist in the original developer's head, code that fights every change, nothing protecting the payment flow, a deploy that works mostly by luck. The report shows you this before you hire, launch, or keep building on top of it, not after.
What this is
I read the code, the docs, and the setup, and write up what I find. You get an honest written assessment. Not a sales pitch for a rebuild, and not the start of an open-ended consulting engagement.
Review coverage
Project organization, entry points, architecture, maintainability, API/backend boundaries, frontend organization, and data model concerns.
Setup instructions, developer experience, testing gaps, dependency/tooling health, documentation quality, and handoff friction.
Developer-level security red flags, auth/authorization concerns, deployment clues, production readiness, scaling assumptions, and cloud cost risks.
Deliverable
I write it for three readers: you, the next developer you hire, and the AI coding agent either of you ends up pointing at the repo.
Example findings
The app may work on the original developer's machine, but the repository does not clearly document environment variables, database setup, migrations, or test commands.
Why it mattersA new developer or AI coding agent may waste hours trying to run the project.
The app may check whether a user is logged in, but not consistently check whether that user can access or modify a specific resource.
Why it mattersThis can create privacy, data access, and security risks before launch.
Important flows such as sign-up, payments, permissions, uploads, or data changes may have little or no regression protection.
Why it mattersFuture changes become risky because breakage may only be found after users are affected.
The repository may contain old setup paths, outdated commands, or conflicting handoff notes.
Why it mattersDevelopers and AI agents can follow stale instructions and make unsafe assumptions.
Sample report
Don't take my word for the level of detail. Read one. The sample is based on a fictionalized AI-built SaaS MVP, but the format, depth, and recommendations are exactly what you'd get.
Open sample PDFIncludes: client takeaway, readiness scores, top findings, quick wins, first PRs, and AI-agent tasks.
Redacted: no private repo names, customer data, secrets, or internal project details.
Pricing
Founding customer rate
R3,000 / US$200
Regular pricing from R9,500 after the founding window.
Why this cheap? I'm collecting founding customers: the rate is a trade for a short testimonial and permission to write up your review as an anonymized case study.
Best for MVPs, AI-built prototypes, small SaaS apps, freelancer-built apps, and projects being prepared for handoff or beta launch.
If the report doesn't tell you anything you didn't already know, you don't pay.
Request a reviewProcess
Share what the app does, what worries you, and what stage it is at.
Do not send production credentials, private keys, live API secrets, or customer data.
I work through the repo within a fixed scope: setup, architecture, tests, red flags, readiness.
In writing: what matters now, what can wait, and where I'd start.
Who reviews your code
Every review is done by me, an engineer with an MSc and 5+ years building large-scale production systems at one of the world's largest tech companies. Reviewing code is part of my day job. Your MVP gets the same standard.
I do use AI tools during the review; they're good at coverage. But every finding, severity rating, and recommendation in your report is something I've checked myself and stand behind. You're not paying for a tool's raw output.
Scope boundaries
I'd rather tell you now than disappoint you later. This is a readiness review. It is not a penetration test, not a security certification, not emergency production support, not a rewrite or deployment service, and not a substitute for specialist legal, compliance, or security advice.
Please do not send production credentials, private keys, live API secrets, or customer data.
FAQ
Honestly, try it. It's a reasonable first step, and I use AI tools in my own process. The problem is that a chatbot reports everything it notices with roughly equal confidence, and nobody is accountable if it's wrong. My job is the opposite: rank what actually threatens your launch, tell you what can safely wait, and stand behind the call.
Not as part of the report, and that's deliberate. A reviewer who profits from finding problems has a reason to inflate them. If you want help with the fixes afterwards, I'll quote that separately once you've read the report.
No. I flag developer-level security issues when I see them, like missing authorization checks, exposed secrets, or risky webhook handling, but a proper penetration test is a different discipline and I won't pretend otherwise.
No. You fill in the form, I review, you get the report. If something in your intake is unclear, I'll ask by email.
Then that itself is a finding. If I can't get the app running from your instructions in a reasonable time, neither can your next developer. I continue with a static review and document exactly where setup broke down.
Yes, they're the main reason this service exists. AI tools produce code that demos well, and the gaps tend to hide in the same places: authorization, error handling, webhooks, tests. If you vibe-coded your way to something that works, this tells you whether it will survive real users.
Ready before you build further