How a rendering review works

Nine steps from first message to retest

1. 01

   First message

   You write to us through the contact page with a few lines about the app, its framework and what feels slow. We reply by email with questions, not a sales script.

2. 02

   Scoping call

   A 30-minute video call, or an email exchange if you prefer, to agree routes, interactions, devices and access. There is no charge for this conversation.

3. 03

   Written quote

   You receive a fixed price, the list of deliverables, what we need from you and a proposed start date. Nothing is owed unless you accept it in writing.

4. 04

   Access and baseline

   You set up test accounts and any read access through invitations you control. We agree which build counts as the baseline, so later comparisons are fair.

5. 05

   Measurement

   We gather field data where it exists and record traces on fast and throttled profiles, several runs per route so one noisy run does not mislead.

6. 06

   Diagnosis

   Every slow moment gets a named cause and the evidence for it. We share early notes if something urgent turns up, such as a production error.

7. 07

   Findings and walkthrough

   You receive the written findings, ranked by their effect on users, with the trace files. A walkthrough call lets your engineers question every point.

8. 08

   Implementation, if you want help

   Your team ships changes, with optional pull request review or hands-on engineering quoted separately.

9. 09

   Retest

   Once changes reach staging or production, we repeat the original traces and, when enough visits have accumulated, compare field data.

Timelines

A standard review typically takes around two weeks from the agreed start date to the walkthrough call; the exact dates are confirmed in your quote. Larger scopes and strategy reviews with prototypes take longer, and the quote states the expected dates. Field data takes longer still to reflect a change, because the Chrome UX Report aggregates over a rolling 28-day window (source 1). Your own monitoring, if you have it, shows the trend sooner.

What changes the timeline

Three things lengthen a review more than anything else: waiting for access, sparse field data that has to be collected first, and scope added after the start. We plan for the first two in the quote, by asking for access before the start date and by stating whether data collection is part of the work. Scope changes are quoted separately so the original timeline stays clear.

After the engagement

Follow-up support after the walkthrough is optional and quoted with the review if you want it. You can also book a retest or further help later, or simply keep the findings and work through them yourselves. There is no retainer or subscription unless you ask for one.

How we handle access and data

We ask for the least access that lets us do the work. Test accounts with seeded or anonymized data are better than real customer accounts. We never ask for passwords by email or chat; access goes through invitations, temporary accounts or your own identity provider, and you remove it when the work ends. Trace files can contain URLs and page content, so we store them only for the length of the engagement plus 30 days, then delete them unless you ask us to keep them. The privacy notice covers the information we handle about you as a contact.

How we communicate

Email is the default, with calls where they help. We work in English and schedule calls during Canadian business hours, adjusting for time zones from Newfoundland to British Columbia. If a question comes up during the work that only your team can answer, we ask rather than guess.

Roles on your side

A review goes most smoothly with three people named at the start, although one person can cover all three in a small team:

• An owner who agrees the scope, answers questions about priorities and receives the findings.
• An engineer who can set up access, explain how the app is built and deployed, and join the walkthrough.
• Someone close to users, such as a product manager or support lead, who knows which screens people complain about. Their input often decides which routes and interactions are in scope.

We keep meetings short and few: the scoping call, an optional midpoint check if the work turns up something surprising, and the walkthrough.

How findings move into your backlog

Findings are written so each one can become a ticket: a title, the evidence, the proposed change, the effort and the risk. On request we deliver them as a CSV or Markdown file that imports cleanly into common issue trackers. During the walkthrough we suggest an order of work, but the order is your decision; you know your release plans and constraints better than we do.

Questions about the process