The Zenveus Production Readiness Standard

The nine checks at a glance

Weights sum to 100. Authorization carries the most weight on purpose: tenant and data isolation is where AI-built apps most often leak. Criteria marked [C] are critical; there are ten across the nine checks.

01. Who can get in? Authentication and access control

Weight 12. Pass at 90 or above. Passing means no privileged route is reachable without a valid, expiring session, and nobody can promote themselves.

• [C]No unauthenticated route exposes admin or privileged functionality.
• Sessions expire, rotate on privilege change and invalidate on logout.
• Credentials are hashed with a modern algorithm. No plaintext or reversible storage.
• MFA is available for privileged accounts, or documented as out of scope with a reason.
• Login and reset flows are protected against brute force and credential stuffing.
• A user cannot set their own role through the signup or profile request.

Evidence that counts: the route list with its auth middleware, a session-expiry test, the signup handler showing the role is set server-side.

02. Can one user read another user's data? Authorization and data isolation

Weight 16. Pass at 95 or above. Passing means every read and write is scoped on the server to the right user and tenant, and changing an id in a request returns nothing.

• [C]No record is reachable by changing an id in the request.
• [C]Row and tenant isolation is enforced on the server, not in the client.
• Every mutating endpoint checks role and permission, not just the UI.
• Admin and impersonation paths are logged and scoped.
• Stored files and buckets are not publicly listable or guessable.

Evidence that counts: row-level security policies or equivalent server checks, a cross-tenant regression test, bucket policies. The interface showing only your rows is not evidence; the API returning only your rows is.

03. Is a secret in the bundle? Secret and key management

Weight 14. Pass at 90 or above. Passing means no service, API, payment or database secret can be found in the frontend, the repository history or the logs.

• [C]No service, API, payment or database secret ships in the frontend bundle or a public repo.
• Secrets live in a managed store or the environment, never in source control.
• Keys are rotatable, and rotation has been done at least once.
• Third-party tokens are scoped to least privilege.
• No secret appears in logs, error messages or client-visible responses.

Evidence that counts: a scan of the built client bundle and git history, the environment configuration, a rotation record.

04. What happens on bad input? Input validation and error handling

Weight 10. Pass at 85 or above. Passing means untrusted input, including AI prompts and AI outputs, is validated on the server, and failures fail safe.

• [C]Injection (SQL, NoSQL, command, template) is unreachable on every write path.
• All untrusted input is validated on the server. Client validation is not relied on.
• Errors fail safe: no stack traces, internal ids or personal data reach the client.
• LLM prompts are built so user input cannot pull out system instructions or other users' data.
• AI outputs that trigger actions (tool calls, writes) are validated before they run.

Evidence that counts: server-side validators on each write path, an error response captured in production mode, the prompt assembly code and the validator in front of any AI-triggered action.

05. Can a payment be double-charged or faked? Payments and transactional integrity

Weight 12. Pass at 95 or above. Passing means webhooks are verified and replay-safe, money-moving operations are idempotent, and the server sets every amount.

• [C]Payment webhooks are signature-verified and replay-safe. No double credit.
• Money-moving operations are idempotent under retry.
• Internal records reconcile with the payment provider.
• Refunds, disputes and partial states are handled, not just the happy path.
• Prices and amounts are set by the server, never trusted from the client.

Evidence that counts: the webhook handler with signature check and idempotency key, a replayed-event test in provider test mode, a reconciliation query.

06. What breaks at a hundred users? Performance and scalability

Weight 8. Pass at 80 or above. Passing means expensive paths are rate limited, no loop can run up an abuse-case bill, and third-party failure degrades instead of crashing.

• [C]No uncapped LLM, loop or recursion path can be driven to an abuse-case bill.
• Public and expensive endpoints are rate limited.
• N+1 and unbounded queries on the hot path are found and bounded.
• Third-party failures degrade gracefully (timeout, retry, fallback) instead of hanging or crashing.
• A rough load ceiling is known and written down.

Evidence that counts: rate-limit configuration, per-user and per-request caps on AI calls, a load test at two to three times expected peak, the written ceiling.

07. Does anything stop a broken change from shipping? Automated testing and CI

Weight 8. Pass at 80 or above. Passing means every money and auth path has a test, and CI blocks a failing change.

• [C]Every money path and every auth or authorization path has at least one automated test.
• CI runs the tests and blocks merge or deploy on failure.
• Critical user journeys have integration or end-to-end coverage.
• Test data and secrets are separate from production.

Evidence that counts: the test files for the money and auth paths, the CI configuration, a failed run that blocked a deploy.

08. Will you know before a customer tells you? Observability and deployment

Weight 8. Pass at 85 or above. Passing means errors reach a human, deploys are scripted, and rollback has been exercised on production.

• [C]A rollback path exists and has been exercised on the production deploy.
• Structured logs and error tracking are in place, and errors reach a human.
• Alerts fire on the failures that matter: auth errors, payment failures, error-rate spikes.
• Deploys are scripted or run through CI, not manual and undocumented.
• Ownership, a runbook and setup docs exist, so a new engineer can operate the system.

Evidence that counts: the rollback runbook and one recorded exercise, the alert rules and where they deliver, the deploy pipeline.

09. Could you survive a review? Compliance and audit surface

Weight 12. Pass at 90 or above. Passing means sensitive data is classified, access to it is logged, sensitive actions leave an audit trail, and you know which third parties see what.

• [C]Sensitive and personal data is classified, and access to it is logged (critical wherever a regulator would require it).
• Data egress and residency are known and documented: which third parties see what, and where it is stored.
• Sensitive actions leave a tamper-evident audit trail (who did what, when).
• Retention and deletion are defined and enforced.

Regulated overlays. The overlays add criteria only when the system carries that kind of data. Insurance mode: claims-state and policy-data correctness, broker and producer permission boundaries, carrier and rating-engine integration data handling, agency-management-system reconciliation, state-filing data handling. Healthcare mode: PHI data flow mapped, PHI-safe logging, BAA scope defined, minimum-necessary access, audit trails that survive a review, EMR handoff integrity. An overlay item is claimed only where a system Zenveus delivered actually touched it.

How scoring works

• Evidence first. Every criterion is scored on evidence. Anything without evidence is treated as unknown and does not count as a pass.
• Per criterion: Pass scores full marks, Warn scores half, Fail or Unknown scores zero.
• Per check (0 to 100): the average of its criteria, times 100. A check passes when its score meets its threshold.
• Overall (0 to 100): the weighted sum of the nine check scores.
• Critical cap: if any [C] criterion fails, the overall score is capped at 54, "Not production ready", no matter how good everything else looks. A clean-looking app that leaks tenant data is not an 80.
• Bands: 0 to 54, Not production ready. 55 to 74, Ships with named risks. 75 to 89, Production-capable, gaps listed. 90 to 100, Production-ready against v1.0.
• Versioning: this is ruleset v1.0. Every score records the version it was scored against, so a re-score after a rule change is a fair comparison.
• No invented statistics. No percentile or "average score" is published until at least 100 real apps have been scored and 10 Verdicts delivered. Until then, findings are stated as what we see.

A worked example

A fictional app: built in Lovable on Supabase, about 40 active users, Stripe checkout about to go live. The self-check collects evidence; a senior engineer scores it.

Weighted sum: 61. Two critical criteria failed, so the overall score is capped at 54: Not production ready. The verdict is not "rebuild". It is: fix the two critical findings first (a database-level organisation policy plus a cross-tenant regression test; webhook signature verification, an idempotency key and a replay test), then re-score. Most of the rest is contained work. That ordering, with effort bands, is what the written Verdict contains.

Frequently asked questions

Is the Standard a certification?

No. It is an engineering yardstick Zenveus publishes and scores against. It does not replace legal advice, a formal certification such as SOC 2 or HIPAA attestation, or a penetration test. It can prepare a product for those.

Can I score my own app against it?

Yes. The criteria and method are published here in full. The free self-check runs the nine checks against a repository and reports what the code shows. A self-score is your assessment against v1.0, not a signed Zenveus Verdict.

What is the difference between the free self-check and the $299 Verdict?

The self-check collects evidence and gives a provisional score. For $299, a named senior engineer reads the evidence and your codebase, scores it against the Standard, and signs a written decision: keep, repair, selectively replace, or rebuild, with findings your own developer can act on.

Why is one failed critical criterion enough to cap the score?

Because the failures it marks are the ones that end companies: another customer's data exposed, a payment double-credited, a production key in the browser. An app with those open is not production-ready, whatever the rest of the score says.

Does the Standard apply to apps not built with AI?

Yes. The nine checks describe production software. AI-built apps are the audience because that is where the gap between a working demo and a safe product is widest.

How often does it change?

The ruleset is versioned. Changes are published with a new version number and date; existing scores keep the version they were scored against.

Next step

Author: Kumail Pirzada, co-founder and CTO, Zenveus. Reviewed by Ehtasham Ali, co-founder and CEO. Version 1.0. Last updated 2026-10-15. Plain-text version: production-readiness-standard.md.