The Production Readiness Assessment: What You Get Before Any Work Begins
A founder with an AI-built app usually starts the agency conversation the same way: here is what we built, what would it cost to finish it? The usual answer is a proposal. We answer with a production readiness assessment, a paid review that ends in a written report. The report tells you what is solid, what is risky, and what it would actually take to put the app in front of real users.
This article explains what the assessment covers, what the report looks like, and why we structured the engagement this way. If you are comparing partners for an AI app production review, it should also help you judge anyone else’s offer.
Why the First Deliverable Is a Report, Not a Proposal
A proposal written before anyone has read your code is a guess. It has to be. Nobody knows yet whether your authentication holds up, whether the data model can survive a feature change, or whether there are API keys sitting in the repository. So the proposal either pads the price to cover the unknowns or quotes low and renegotiates later. Neither version serves you.
The assessment reverses the order. We read the code, test the app, and inspect the infrastructure first. Then we put the findings in writing. Only after that does anyone talk about a project, because only after that can a quote mean anything.
There is a second reason, and it matters just as much. A proposal is a sales document. A report is a deliverable. When the first thing you pay for is the report itself, the incentive points the right way: our job in that phase is to give you an accurate picture, not to win the next phase.
What the Assessment Examines
The review covers five areas. Each one answers a question a founder eventually has to answer anyway, usually at a worse moment.
The first is architecture. Can a second developer change this code without breaking it? AI tools often produce code that works but resists modification: duplicated logic, tangled dependencies, structures that only make sense if you watched them being generated. We read for that, because it determines what every future change will cost.
The second is security. This is the deepest pass, and it follows a consistent pattern, because AI-generated code tends to fail in consistent ways. We look for credentials committed in the code, authorization that exists only in the interface, injection paths through unvalidated inputs, and endpoints that trust whatever the browser sends.
The third is infrastructure. Where does the app actually run, what happens when that machine restarts, where are the backups, and who gets alerted when something fails? An app that runs on one laptop or one unmanaged server has a single point of failure, and launch traffic tends to find it.
The fourth is data. We map what the app collects, where it sends that data (including to model providers), what gets logged, and how long everything is kept. Most founders are surprised by at least one line of that map, and it is far better to be surprised now than during a customer’s security questionnaire.
The fifth is cost. AI features carry per-use model charges that scale with users, not with features. We look at what your current setup would cost under real usage and whether caps and alerts exist to keep an invoice from becoming the way you discover a traffic spike.
What the Written Report Contains
The report is organized around three lists, in plain English, with the evidence for each item.
The first list is what is solid. This section matters more than people expect. AI-generated codebases are rarely all bad, and knowing what to keep protects you from a partner whose answer to everything is a rebuild. If the data model is sound or the core logic holds up, the report says so, because that work is already paid for.
The second list is what is risky. Each finding comes with what it is, why it matters in business terms, and what happens if it ships unfixed. A hardcoded API key is not described as a code smell. It is described as a credential that an attacker can find and bill against.
The third list is what is required to ship. Not everything risky blocks a launch. The report separates the exposures that must be closed before real users arrive from the improvements that can wait, so you can sequence the work against your deadline instead of treating it as one undifferentiated pile.
The report closes with the price: a quoted, fixed scope for the work the findings call for. The quote can be honest precisely because the review happened first. The padding is gone because the unknowns it would have covered were just removed by the assessment.
Think of it as a code review report for founders. It is written for the person who owns the business decision, with the technical evidence attached, rather than the other way around.
Usable With Us or Without Us
The report is written so that any competent developer or agency can execute it. Findings name the file, the endpoint, or the configuration involved. The required-to-ship list stands on its own as a pre-launch assessment you can hand to whoever does the work.
We built it that way on purpose. If the report only made sense as a preamble to hiring us, it would be a proposal wearing a different name, and the incentive problem would be right back. A report you can take elsewhere keeps us honest, and in practice it also tends to make the case for working together better than a pitch would. You can judge the quality of our thinking from the document itself, before committing to anything larger.
It also means the engagement has a clean exit at every step. You can stop after the report with a complete, usable artifact. Plenty of founders do exactly that, fix what they can in-house, and come back later for the parts they would rather hand off.
What Happens After: From Findings to a Fixed-Scope Plan
When you do want help with the fixes, the report converts directly into a plan. The required-to-ship items become the first phase, sequenced so that security exposures close before anything else, since those are the findings that get worse with every day of real traffic. Stability and infrastructure work follows, then the improvements that were safe to defer.
Because the scope comes from documented findings, the plan is fixed rather than open-ended. Each item traces back to something the report identified, which means you can see what you are paying for and verify when it is done. If new issues surface mid-project (it happens, usually in the oldest corners of a codebase), they get written up the same way and decided on separately, instead of silently inflating the original number.
All of the work happens in your accounts: your repository, your hosting, your domains. That is standard for every engagement we run, and the report notes anywhere your current setup does not give you that ownership.
The assessment exists because the gap between a working demo and a supportable product is real, and guessing at its size serves nobody. Request the assessment. The report is yours either way.