Is Your App Actually Ready for Production?
Built by AI, by a vendor who's moved on, or by a team that's since scaled — here's how to find out what's underneath before your users do.
Most applications don't fail because they were built badly. They fail because nobody checked the six things that only matter once real people show up. Work through them below. No email required.
What "production-ready" actually means
An application is production-ready when it can survive contact with real users, real data, and real failure — without losing information, exposing anything it shouldn't, or needing the person who built it to be awake.
Readiness isn't a measure of whether your app works. It's a measure of whether it keeps working once conditions stop being ideal.
Security & Data Protection
Whether anyone can reach data they shouldn't through exposed endpoints or flawed authorization rules.
Scale & Performance
Whether database queries and server threads hold up smoothly as concurrent usage grows.
Reliability & Incident Readiness
Whether you get alerted the moment something breaks, and have a proven path to restore last known good state.
Compliance & Data Obligations
Whether you can clear security questionnaires, honor privacy requests, and answer for the user data you hold.
Code & Handoff Health
Whether anyone besides the original builder can safely modify features without unravelling the system.
Launch & Discoverability
Whether users can find the product, onboard without help, and reach a responsive support channel when stuck.
No application scores full marks on all six — and none needs to. An internal tool with forty users carries different obligations than a platform holding student records. What matters is knowing which of your gaps are load-bearing — the ones that cost you a customer, a deal, or a disclosure — and which can wait.
Where did your app come from?
System risks depend heavily on how your application was built. Select your origin scenario below to reveal your target audit path.
Structural Risk: Unwritten Security & Runtime Gaps
AI generators optimize for functional speed, leaving authorization rules, rate limits, and failure handling unwritten.
Structural Risk: Frozen Product & Roadmap Lock
The primary risk is that you can't safely change anything without unravelling the system, forcing business decisions to route around your product.
Structural Risk: Unproven Data & Security Claims
Your application runs smoothly, but "it works" turns out to be a very different claim from "we can prove it's safe to an enterprise buyer."
Internal AI tools touching customer data carry all three risks at once: code nobody reviewed, unassigned ownership, and unverified data obligations.
The 6 Dimensions of Launch Readiness
An application is production-ready when it can survive contact with real users, real data, and real failure. Work through the six core audit dimensions below to identify your load-bearing gaps.
Can anyone reach data they shouldn't?
Security has the shortest distance between a small mistake and an unrecoverable breach. Most breaches in small applications aren't sophisticated—they're a public key or an endpoint that trusts whoever calls it. Your interface is not a security boundary. Hiding a button doesn't protect what the button does.
What "Ready" Looks Like
- Secrets live in a managed store—not source code or browser bundles.
- Authorization is enforced on the server for every endpoint.
- Tenant & row-level isolation is verified by tests.
- Dependencies are scanned and pinned to versions.
- Rate limiting covers login, password reset, and write endpoints.
- All traffic is HTTPS with HSTS enabled.
Failures We See Most
API Keys Shipped to Browser
Anything in your frontend bundle is public—including keys assumed to be hidden.
Permissive DB Defaults
Platforms ship permissive so you can build fast. Closing them gets skipped.
UI-Only Auth Checks
The page hides the admin button, but the API serves anyone who calls it.
If Your App Was AI-Built
Auth Degrades Across Prompts
Prompting a login flow tweak often silently removes server-side permission checks.
Hardcoded Credentials
Generators take the shortest path to working code—which bakes secrets in.
Will it hold up when more people use it?
Performance problems are rarely gradual. Systems are fine until a hidden query pattern breaks under volume. The useful question isn't is it fast—it's what happens at 10× this, and which part gives first.
What "Ready" Looks Like
- Response times (p50/p95) are measured and baselined.
- System is load-tested to 10× expected peak.
- Filtered and joined database columns have indexes.
- List views avoid N+1 query patterns.
- Heavy tasks (PDFs, emails) run in background workers.
Failures We See Most
Never Load-Tested
First real traffic spike becomes the first actual stress test.
Synchronous Heavy Work
Generating reports inside page loads blocks server threads for all users.
Unpaginated Endpoints
Fine at 200 records. Completely fatal at 200,000 records.
If Your App Was AI-Built
Synchronous Sequential Code
Generators favor simple sequential code—easier to write, but slow under load.
Missing Indexes
Generators don't anticipate data growth, omitting basic database indexes.
Will you know when it breaks, and can you put it back?
Every system fails eventually. The difference between an incident and a crisis is whether you hear about it from a monitor vs. a customer. Nothing looks wrong until the day everything is.
What "Ready" Looks Like
- Error tracking captures production stack traces.
- Uptime alerts notify a named human directly.
- Logs are structured and stored off-server.
- Automated backups have been restored and tested.
- Rollback procedure is documented for anyone to follow.
Failures We See Most
No Automated Alerting
Learning about outages from an angry customer email hours later.
Untested Backups
An untested backup is a hypothesis, not a safeguard during incidents.
No Rollback Path
Bad deploys force panicked forward fixes under intense pressure.
If Your App Was AI-Built
Monitoring Omitted
Monitoring isn't a functional requirement, so AI leaves it out entirely.
Console-Only Logs
Logging prints to stdout on a server nobody is actively reading.
Can you answer for the data you hold?
Compliance kills deals, not servers. It manifests as security questionnaires you can't complete and procurement processes that stall. This becomes the gate on your revenue.
What "Ready" Looks Like
- Written data inventory: what lives where & retention.
- FERPA & COPPA controls active for student data.
- SOC 2 controls mapped for enterprise sales targets.
- WCAG 2.2 AA conformance for education buyers.
- Working data deletion workflow for individual requests.
Failures We See Most
No Data Inventory
Security questionnaires arrive and nobody can answer basic data flows.
Data Residency Mismatch
Data sits in cloud regions prohibited by enterprise customer policy.
Manual Deletion Only
Fulfilling privacy deletion requests requires risky manual SQL edits.
If Your App Was AI-Built
Undisclosed Subprocessors
AI wires in 3rd-party APIs without flagging mandatory user disclosures.
PII Inside Application Logs
Personal data recorded in unmonitored logs extends retention duties.
Can anyone besides the original builder work on this?
A system only one person or tool can modify isn't an asset—it's a dependency. Every month of changes to an unmaintainable codebase makes untangling more expensive.
What "Ready" Looks Like
- Version control with history explaining changes.
- README gets new engineers running in <1 hour.
- Lockfiles ensure reproducible builds.
- Automated test coverage on revenue-critical paths.
- Database migrations manage schema changes cleanly.
Failures We See Most
No Local Setup Path
The application only runs where it was originally created.
Single-Account Deploy Button
Deployment is locked inside one person's personal account with no backup.
Zero Automated Tests
Without tests, nobody can safely modify code, destroying velocity.
If Your App Was AI-Built
Code Sprawl & Duplication
Massive files with duplicated logic because prompts solve tasks in isolation.
Unversioned Database Drift
AI alters tables directly rather than generating tracked migration files.
Can people find it, use it, and tell you when it's broken?
Launch instrumentation is often skipped as "marketing," but it's essential engineering. Without instrumentation, you operate blind on launch day.
What "Ready" Looks Like
- Event analytics tracking user actions, not just pageviews.
- Clear user problem reporting channel actively monitored.
- Frictionless self-service onboarding path tested.
- SEO technical fundamentals: titles, sitemap, meta, schema.
- End-to-end billing tested: declines, retries, refunds.
Failures We See Most
No Event Analytics
When features break, you can't identify affected users or actions.
Blocking robots.txt
Staging blocks left active for weeks after production launch.
Happy-Path Only Billing
Card declines leave accounts in unexpected, unhandled states.
If Your App Was AI-Built
Placeholder Legal Terms
Unreplaced boilerplate legal pages create liability when taking payments.
Unverified Webhooks
Payment webhooks generated without signature checks or idempotency.
What These Gaps Actually Cost
Readiness gaps rarely announce themselves. They surface at the worst possible moment — usually while someone else is evaluating you.
Pipeline Freeze & Unrecoverable Sales Cycle
You spend a quarter on an enterprise or district opportunity through demos and pricing. Then it reaches security review.
The questionnaire asks where data lives, who holds access, and whether you've run penetration tests. The honest answers are worse than the gaps. The deal doesn't get rejected — it stalls and quietly dies.
Legal Deadlines & Reputational Damage
A credential left somewhere public gets found by an automated scanner. Someone reaches user data they shouldn't.
What follows isn't mainly a technical problem. It's notification obligations with legal deadlines, outside counsel, customer conversations, and reporting duties. The customers who leave don't come back.
Technical Debt Lock & Duplicate Expense
You need a significant change, and the codebase can't safely absorb it. There are no tests, no clear structure, and nobody who understands the whole.
So you get a quote to rebuild what you already have. It costs a multiple of the original build and adds no new capability while competitors keep moving.
Unmonitored Failures & Unexplained Retention Decay
Nothing dramatic breaks. A payment webhook fails intermittently, a feature errors on one browser, or an email stops sending.
With no monitoring, nobody notices. Users hit the problem, decide the product doesn't work, and leave without filing a ticket. Your metrics show weakening retention with no cause.
Most of this is smaller than it sounds
The word "audit" makes people think "rewrite," and rewrites are the reason a lot of founders never look under the hood at all. In practice most readiness gaps are contained pieces of work — days rather than months, and independent of each other, so they can be sequenced around whatever else you're doing.
Rotate every exposed key, move them into a managed store, purge them from git history, then confirm nothing depended on the old arrangement.
Impact & Scope: Largely independent of how big the app is. The work scales with the number of keys, not the size of the codebase.
Every endpoint gets an explicit permission check, and the interface stops being the thing that decides who sees what.
Impact & Scope: Depends entirely on how many endpoints you have. Apps built by prompting sit at the longer end because each route was solved on its own without a shared pattern.
Error tracking, uptime alerts to a named person, structured logging, a health check, and one restore actually performed to prove the backups work.
Impact & Scope: This is the highest-value-per-hour work on the list, turning future incidents from discovery problems into response problems.
Documenting what personal data you hold, where it lives, who can reach it, and how long you keep it — then building a deletion path if there isn't one.
Impact & Scope: What takes time is finding forgotten places data ended up: log files, analytics tools, and third-party integrations wired in earlier.
Local setup that reproduces, environment configuration pulled out of the code, a baseline migration so schema changes are tracked, and tests on the paths where failure costs money.
Impact & Scope: If the app runs locally today, it's the short end. If it only runs where it was built and the schema was edited by hand, reconstruction takes longer.
Event analytics, a support channel someone reads, billing failure paths tested properly, and legal pages that describe your actual product.
Impact & Scope: Mostly configuration rather than engineering — which is why it's so often the last thing done and the first thing to cause an avoidable problem.
Sequence matters more than completeness
None of these are rewrites. They're contained pieces of work you can do one at a time.
They're also not equally urgent. A team that fixes exposed secrets and adds monitoring, then does nothing else for three months, is in far better shape than one working evenly through all six.
That's what knowing where you stand actually buys you — not a longer to-do list, but a shorter list of real priorities.
Score your readiness
Thirteen questions, about ninety seconds. Nothing is stored or sent — close this tab and it's gone.
Frequently Asked Questions
Clear answers on what happens after you score your readiness, how audits work, and how gaps get fixed.
We start with a 30-minute scoping call with Taylor Basilio, our CEO and working engineer. We review your app's architecture, hosting setup, and self-assessment results.
From there, our engineering team inspects your codebase across the six core readiness dimensions and produces a prioritized, written audit within 48 hours — outlining what's urgent and what can wait.
No. Your answers live entirely in your browser's local memory. No form submissions are made, no cookies are saved, and no data is sent to server logs.
When you close or refresh this tab, your answers are gone completely.
AI builders excel at functional speed, but routinely omit load-bearing runtime controls. The most common AI gaps we fix are:
1. Hardcoded API credentials shipped in frontend bundles.
2. UI-only authorization checks without server-side endpoint verification.
3. Sequential/synchronous queries that freeze under concurrent user load.
4. Unversioned database migrations that make future edits risky.
Rarely. Most critical launch gaps — such as moving secrets off the browser, adding server-side auth guards, or testing database backups — can be remediated in place without touching your core UI or product logic.
A full rewrite is only necessary when database schemas or core framework choices are unmaintainable. Our goal is to patch load-bearing gaps so you can launch safely.
Yes. We offer both fixed-scope gap remediation projects and dedicated engineering pods.
Our US-led engineering team can step in, patch your critical security or performance vulnerabilities, set up automated tests, and ensure your app is production-ready.
We evaluate controls for FERPA, COPPA, and WCAG 2.2 AA accessibility conformance.
We verify student data isolation, deletion request paths, subprocessor DPAs, and accessible DOM structures required to pass district and university procurement reviews.
You've seen the list. Now the harder question.
Everything above is triage. Twelve questions can tell you whether you probably have a problem — they can't tell you how bad it is, what it would cost to fix, or what to do first. That takes someone looking at the actual code.
Path A — Readiness Audit
If you want to know exactly what you're running. We inspect your codebase across all six dimensions and produce a working list ordered by urgency with an honest estimate of effort for each item.
- Written findings across all six dimensions, rated and explained in plain terms.
- Prioritized fix list separated into before launch and can wait.
- Effort estimates against each item so you can decide what to fix in-house.
- 45-minute walkthrough call with Taylor Basilio to answer questions.
What it costs: A fixed price, quoted before any work starts. Not hourly, not scoped after the fact — you'll know the exact number before you commit.
What we need: Read access to the repository and a description of what the app does. We sign a standard NDA before you send anything.
Best for: Apps built with AI tools, inherited codebases, or anyone who answered "I don't know" above.
Path B — Architecture Call
If you already know the problem and need to plan the fix. A direct technical conversation with Taylor Basilio, our CEO. He's a working engineer, not a salesperson — you'll leave with a clear view on sequencing whether or not you work with us.
What happens on the call: Bring whatever you found in your self-assessment — including the parts you couldn't answer. Taylor will walk through what's genuinely urgent, what can wait, and roughly what each fix would take.
Best for: Teams who can already name their gap, or who have a specific deadline — an enterprise deal in security review, an upcoming launch, or an audit scheduled.
"Will you just tell me to rebuild it?"
No. Rebuilds are expensive, slow, and usually unnecessary — most of what we find is fixable in place. If we do think a rewrite is the right call, we'll show you the specific reasoning rather than asserting it, and you're free to get a second opinion on that reasoning.
"I built this with AI. Is that going to be a problem?"
Not with us. A meaningful share of the applications we assess now started this way, and the gaps are consistent enough that we know where to look before we open the repository. Building fast and then checking is a reasonable strategy. It only fails if the checking never happens.
"What if it turns out we're fine?"
Then we'll say so, and you'll have paid a fixed, known amount to find that out. That's a good outcome — considerably cheaper than discovering it the other way. We'd rather tell you that than manufacture work.
Not sure which of these fits? Send us a quick note to Our Team — describe what you've got in a couple of sentences and we'll tell you which path makes sense, or whether neither does.