Qognis Studio · Audit deliverable
Sample
The stated question
Rebuild the checkout on the current stack, or replatform first?
- Prepared for
- A client (redacted)
- Format
- Audit · €3,000 fixed
- Elapsed
- 9 working days
- Verdict
- Not yet
This is a sample. The structure, the depth, and the verdict format are what a client receives. The findings themselves are invented for illustration, because real audits are confidential and we don't publish other people's problems — or fake case studies.
01 — One question, agreed in writing
An audit answers one question, fixed at intake before any work starts. Anything we find that doesn't help answer it stays out of the report. That is what keeps a report at reading length instead of sixty pages.
02 — What was examined
The report opens with a list of what we read and ran. In this sample: the repository, production logs for the retry defect, three months of checkout analytics, the purchase journey walked end to end, and two sessions with the engineers who own the code. Every finding cites its source. Nothing rests on impression.
03 — Findings, by consequence
Each finding carries a severity, the evidence behind it, and what it costs you. They are ordered by consequence, not by where we found them.
Checkout state is duplicated between the cart service and the storefront session; the two disagree after a payment retry.
Evidence — Reproduced twice in staging. Matches four support tickets from May.
Consequence — Double-charges are possible under retry. This defect is behind the tickets that prompted the audit.
Rendering and business rules share one module boundary, so every pricing change forces a full regression pass.
Evidence — CI history: three of the last five releases show the same regression pattern.
Consequence — Lead time is spent on re-testing, not building. Splitting the boundary pays for itself within two release cycles.
Loading and error states are inconsistent across the six highest-traffic views.
Evidence — Recorded walkthrough of all six views, annotated.
Consequence — Perceived quality trails actual reliability. Fix opportunistically; not worth its own project.
04 — The verdict
Not yet. Fix the retry defect first: it is cheap, urgent, and survives either stack decision. Replatforming now would carry the defect with it. Revisit the question once the second market's volume is real rather than projected. When the honest verdict is a smaller format, or no engagement at all, the report says that too — the audit is paid for the verdict, not the outcome.
05 — The written path
One page, three moves, each priced against the public ledger: fix the retry defect (a Focused Build), split the module boundary (a Build Sprint), revisit replatforming in Q3 with real volumes. We walk it through together in the decision meeting, and the plan becomes the scope of whatever the client chooses next.