SAMPLE REPORT
Five risks. A plan the team can use.
Read an example Frontend Risk Audit for Magnificent Invoices: what goes wrong, why it matters, and what the team should do next.
FICTIONAL PRODUCT · ILLUSTRATIVE FINDINGS
Magnificent Invoices, a B2B invoicing product.
A React and Next.js application with TypeScript. Customers open shared document links; staff create, preview and save invoices. Changes to the editor have become difficult to review.
The product, code and examples below are invented. They demonstrate the report format and reasoning; they are not client findings or measured results. Any resemblance to real companies, products or people is purely coincidental.
THE FIVE FINDINGS
Correct the output. Then make changes safer.
Start with document access and invoice totals (01, 04). Follow with data checks and loading (05, 02), then separate the editor with tests in place (03).
DOCUMENT ACCESS · FIX FIRST
A valid document link shows an empty list.
Example evidence
The link uses the customer's name as a lookup key. Two Unicode spellings of José look identical but do not match. One request returns documents; the other returns HTTP 200 with an empty list.
Jos\u00E9 → documents found
Jose\u0301 → HTTP 200 · []Why it matters
Customers can mistake a failed lookup for missing documents. The screen gives them no way to tell the difference.
Recommended action
Use the stable customer ID supplied by the API in new links. Agree support for existing name-based links with the API owner, and distinguish lookup errors from a genuinely empty list.
How to verify
Both spellings open the same documents. Existing links still work, while an unknown customer produces a clear error.
LOADING · WEEK 2
Opening the list also loads the editor and export tools.
Example evidence
In the example dependency graph, the invoice-list entry imports the editor and PDF export module. Both enter the initial load although neither is used to read the list.
InvoiceList
→ InvoiceEditor
→ PDF exportWhy it matters
Every visit downloads and processes code for actions the user may never take. This adds avoidable work before the list is ready.
Recommended action
Load the editor when editing starts and the existing PDF library when export is requested. Show a loading state, handle failures and allow a retry.
How to verify
A fresh list visit makes no editor or export request. Both actions still work. Compare transferred JavaScript and list readiness under the same device, network and cache conditions.
CHANGE RISK · WEEK 3
The editor couples totals, saving and screen state.
Example evidence
The same component owns line edits, discount rules, saving and preview state. A change to rounding touches both rendering and save preparation; focused checks require mounting the whole editor.
InvoiceEditor
lines + totals + save + previewWhy it matters
A small change crosses several behaviours. Reviewers have to check a wider area, and failures are harder to isolate.
Recommended action
Write behaviour tests against agreed product rules before restructuring. Reuse the shared calculation from 04, then separate save handling. Add unit tests for calculations and integration tests for editing, saving and failures. Limit this phase to calculation and save boundaries.
How to verify
The tests fail on known defects and pass after correction. An end-to-end test covers create → edit → save → reopen. Internal restructuring preserves these checks because they assert behaviour, not component internals.
INVOICE CORRECTNESS · FIX FIRST
The editor and preview show different totals.
Example evidence
For three lines of €19.95 with a 10% discount, the editor rounds each discounted line; the preview rounds after adding them. With half-up rounding, the same invoice shows €53.88 and €53.87 before tax.
Editor €53.88
Preview €53.87Why it matters
Staff cannot rely on the displayed total when checking an invoice. One cent exposes a disagreement in the calculation rules.
Recommended action
Agree the rounding rule with the product owner and API owner. Implement one shared calculation for the editor and preview, with explicit decimal handling, and check it against the server result.
How to verify
Tests cover discounts, quantities and rounding boundaries. The editor, preview and server agree on the approved examples.
DATA VALIDATION · WEEK 2
TypeScript passes. An API response still breaks the screen.
Example evidence
The API response is cast to Invoice without checking its shape. When customerName is null, calling trim() throws. A type assertion changes what the compiler assumes; it does not validate the response.
const invoice =
(await response.json()) as Invoice;
invoice.customerName.trim();
// API: { customerName: null }Why it matters
A successful build leaves this failure undetected. One unexpected field can stop the invoice view from rendering.
Recommended action
Validate unknown data at the API boundary. Model nullable fields accurately, replace any in the affected path, and show a recoverable error for an invalid response.
How to verify
Boundary tests reject invalid data and accept valid invoices. An integration test confirms that a malformed response shows an error with a retry action instead of breaking the page.
ILLUSTRATIVE 30-DAY PLAN
An order of work, with a check at every step.
This is a planning window alongside the team's normal work. The team should estimate effort and confirm capacity before committing to dates; implementation is separate from the audit.
Week 1
Restore reliable links and totals
FINDINGS 01 + 04
Work
Add regression tests for the failing links and totals. Fix customer lookup and agree one rounding rule for the editor, preview and API.
Complete when
Existing links open the expected documents. All three calculation paths agree on the approved cases.
Suggested owner: Frontend, with Product and the API owner
Week 2
Check incoming data and reduce loading
FINDINGS 05 + 02
Work
Validate invoice responses and test error recovery. Defer editor and export modules; compare loading before and after under matching conditions.
Complete when
Invalid data has a clear recovery path. The list loads less JavaScript, and editing and export still work.
Suggested owner: Frontend, with QA
Week 3
Separate the editor with tests in place
FINDING 03 · BUILDS ON 04
Work
Before restructuring, write tests from the agreed rules. Separate calculation and save handling. Add unit and integration tests, plus create → edit → save → reopen coverage.
Complete when
Tests catch the known defects and pass after correction. They check expected behaviour without depending on the editor's internal structure.
Suggested owner: Frontend, with Product and QA
Week 4
Verify the changes and record what remains
FINDINGS 01–05
Work
Repeat the report's scenarios, review the loading comparison and check error handling. Update each risk with evidence and any remaining work.
Complete when
Each finding is closed, reduced or still open, with a reason, supporting evidence and an owner for the next action.
Suggested owner: Frontend and QA, reviewed with Product
Correct document access and invoice totals first. Establish tests before changing the editor's structure. Any further editor work depends on what this limited extraction reveals.
What your team should be able to decide.
Which risks deserve attention, why they come first, and how to check the result. A real report bases those decisions on your product, evidence and constraints.
See what is included in the audit →Want this clarity for your product?
Tell us what concerns the team. We'll start by confirming whether the audit is a good fit.
Request availability