CAPABILITY / PRODUCTION-READINESS AUDIT
Know what blocks production before real data arrives.
A production-readiness audit is an engineering review of an application before it holds real customer data, or before a customer's security review. We read the code, the database rules and the deployment, reproduce each problem we find, and tie it to the file and line that causes it. You receive a classified list of findings, a step-by-step remediation plan with a closure test for every step, and a retest against the original evidence.
10 min read
A working application is not yet a production system.
An application can now reach its first users quickly, with much of its code generated by AI tools and a hosted database configured from the browser. It works in a demo. The open questions appear later: who can read which rows, which keys are in the client bundle, what happens when a deployment fails, and whether a backup has ever been restored.
Teams usually ask for an audit at one of these points:
- A launch with real customer or employee data is scheduled.
- A customer has sent a security questionnaire or asked for a technical review before signing.
- A first engineering hire, an investor or a new partner wants to know what they are inheriting.
- A Québec business is preparing the privacy impact assessment the law requires for a new or overhauled system.
Findings you can reproduce.
Every finding is written so your team can see it for themselves. It includes the file and line, the query or policy involved, the steps to reproduce it in a non-production environment, and what it exposes in plain terms: which data, to whom, under what conditions.
We do not report a finding we could not reproduce or trace to the code. Where something is a concern but not demonstrated, it is listed separately as an open question, with what would be needed to settle it.
A plan that ends in a test.
Each finding receives one classification:
- Blocks launch. Real data should not go into the system until this is closed.
- Blocks a feature. The system can launch with this feature disabled or limited until the fix is in place.
- Debt. Tracked, with a reason it can wait and a point at which it should be revisited.
The remediation plan orders the work into phases. Every step states what changes, what it depends on, and a closure test: a check, written before any fix exists, that shows whether the finding is closed.
Areas covered in a typical scope
| Area | What we look at |
|---|---|
| Data access | Row-level security and database policies, roles and grants, service keys, multi-tenant isolation |
| Authentication and sessions | Sign-up and sign-in flows, password reset, session handling, admin paths |
| Server code and APIs | Serverless and edge functions, API routes, authorization checks on each operation |
| Secrets and configuration | Keys in client bundles and repositories, environment separation, development and production data |
| Dependencies and build | Third-party packages, CI/CD, what a deployment can change |
| Continuity | Backups, a tested restore, rollback, monitoring and alerting |
| AI features | Data sent to model providers, tool and action permissions, handling of model output |
| Personal data | Where personal information is stored, who can access it, where it is processed |
The scope is agreed before work starts. Not every area applies to every system.
Teams taking a system to production.
You run a B2B SaaS product, often on Postgres with a hosted backend such as Supabase and a Next.js front end. A launch with real data or a customer security review is coming. You need to know what blocks it, in an order your team can act on, and with evidence you can share with the customer's reviewer.
Québec businesses with Law 25 obligations.
Québec's private-sector privacy act, as amended by Law 25, requires businesses to conduct a privacy impact assessment for any project to acquire, develop or overhaul an information system involving personal information, consulting their person in charge of the protection of personal information from the outset. The act also requires security measures necessary to protect that information and reasonable given its sensitivity, purpose, quantity and medium. The audit gives your privacy officer and legal advisors technical input for that work: where personal information is held, who can reach it, and which technical gaps exist. It is not legal advice and does not state whether the business meets the law.
Three separate engagements. You choose how far to go.
- Audit. Findings, classification, the remediation plan and the closure tests. It stands on its own and can be handed to any team.
- Phased remediation. We can carry out the plan alongside your team, one phase at a time, starting with what blocks launch. Each phase ends when its closure tests pass. You can stop after any phase.
- Retainer. Ongoing engineering support after launch: dependency and change review, maintenance of the closure tests in CI, and a defined response scope for incidents.
Each engagement is scoped and agreed separately. Buying the audit does not commit you to the remediation or the retainer.
The audit does not depend on who fixes it.
We also offer remediation, so we separate the two in ways you can check:
- Findings and closure criteria are fixed first. The audit report, with every finding, classification and closure test, is delivered before any remediation work is proposed or quoted. Remediation is a separate proposal, sent after the report.
- You can remediate with anyone. The plan is written for any competent team, including your own. The scope and terms of the audit do not change based on who carries out the fix.
- The retest uses the original evidence. The retest runs the closure tests from the original report, against the original finding IDs. If a finding or test needs to change, the change is recorded as a dated addendum with its reason, and the original stays in the report.
- A different engineer retests. When Lavinium carries out the remediation, the retest is performed by an engineer who did not write the fix, and the retest report states on its first page that Lavinium also performed the remediation.
This is a separation of roles within one firm, not a third-party review. If you need a third party, the closure tests are written so another firm can run them without us.
What you receive
- Findings register. Each finding with an ID, classification, evidence (file and line, query or policy), reproduction steps and a plain-language description of the exposure.
- Summary for decision-makers. Two pages for a founder, a board or a customer conversation: what blocks launch, what blocks which features, what can wait.
- Remediation plan. Ordered phases and steps, with dependencies and the closure test for each step.
- Closure tests. Written as runnable checks where possible (database policy checks, scripted requests, CI checks), otherwise as documented manual procedures.
- Personal data map. Where personal information is stored and processed and who can access it. Technical input for a privacy impact assessment or a customer questionnaire; not a legal assessment.
- Readout session. A walkthrough of the findings with your team, recorded if you wish.
- Retest report (after remediation, by whoever carries it out). Each original finding marked closed, with the passing closure test, or still open.
We do not state that a system meets a law, a standard or a customer's requirements, and the audit is not a penetration test. It gives you and your advisors the technical facts to make those decisions.
How it works
01 / Scope. We agree on the system, the repositories, the environments and the questions that matter to you (a launch date, a customer review, a privacy assessment). You confirm in writing what we may access and test.
02 / Access. Read access to the code and database schema and migrations, and a non-production environment where we can reproduce findings. We do not need production data. Where a test needs data, we use synthetic records.
03 / Review. We read the code, the database rules and the deployment configuration, and run checks against the non-production environment.
04 / Reproduce and classify. Each candidate finding is reproduced and traced to its cause, or moved to the open questions. Then it is classified and placed in the plan.
05 / Readout. We walk your team through the findings and the plan, and correct anything that rests on a misunderstanding of how the system is used.
06 / Report. You receive the full report and the closure tests. Remediation, if you want it from us, is proposed after this point.
07 / Retest. After remediation, the closure tests are run against the original findings and the retest report is issued.
Timing depends on the size of the codebase, the number of environments and how quickly access is in place. We confirm a timeline after scoping, before work starts.
What a finding looks like
Example (synthetic): not from a client system.
| Field | Content |
|---|---|
| ID | F-03 |
| Classification | Blocks launch |
| Finding | The invoices table has row-level security enabled, but its select policy only checks that the user is signed in. Any signed-in user of any tenant can read every invoice. |
| Evidence | supabase/migrations/20260412_invoices.sql, lines 18–24: policy using (auth.role() = 'authenticated'). |
| Reproduction | Sign in as a user of tenant A in staging; request invoices filtered on a tenant B id; rows return. |
| Exposure | Invoice amounts, customer names and billing addresses across all tenants. |
| Plan step | Phase 1, step 2: scope the policy to the user's tenant membership; add an index on the membership lookup. |
| Closure test | Scripted request as a tenant A user for tenant B rows returns zero rows; the policy check runs in CI on every migration. |
BEFORE WE GET TO WORK
A few answers.
You audit and you also sell the fix. Isn't that a conflict?
It can be, so we separate them. The findings and closure tests are fixed and delivered before any remediation is proposed. You can remediate with any team. The retest runs the original closure tests, and when we did the fix, it is performed by an engineer who did not write it and says so on its first page.
Is this a penetration test?
No. We review the code, database rules and configuration and reproduce findings in a non-production environment. We do not perform penetration testing.
Will you access our production data?
No, unless you ask for a specific check and authorize it in writing. We work from read access to the code and schema, a non-production environment and synthetic records.
Does the audit tell us whether we meet Law 25 or pass a customer's security review?
No. It gives you, your privacy officer and your legal advisors the technical facts: where personal information is, who can reach it and which gaps exist. Those decisions and any legal opinion remain yours and theirs.
Our application was largely written with AI tools. Does that matter?
Not for how we review it. We look at what the code and configuration do, whoever or whatever wrote them. Generated code tends to work in a demo before its access rules are complete, which is why the database rules get particular attention.
We are a small team with one application. Is this too much?
The scope is set per system. For one application and one repository, the audit covers those, and the plan is sized for the team that will carry it out.
What happens after the report?
You decide. You can fix the findings in-house, with another team, or with us in phases. The retest can be run by whoever you choose, using the closure tests in the report.
PRACTICAL GUIDES
Before production.
Shipping AI-built apps to production: what the public evidence says ↗
BEFORE REAL DATA ARRIVES
Tell us about the system and the date.
Tell us what the application does, what it is built on, and what is coming: a launch, a customer review or a privacy assessment. We will reply with the questions we need answered to scope the audit.