Stories

What teams said after we walked their build

These notes refer to named engagements on this site. We keep company names off the page unless a team asks to be identified. The work itself is specific: a screen, an event, a store, a constraint.

Two people in conversation across a table in a bright room

From the people who sat the readout

They caught that our new menu screen never fired add_to_cart on Android. We had been reading a drop in food-delivery add-ons as a merchandising problem for two sprints.

Siti Rahmah Product lead, Penang takeaway app Mobile instrumentation audit
The readout ran long. We had to book a second hour because engineering wanted to argue about fragment lifecycle, and the first ninety minutes were not enough. I still use the payload samples they pasted into the report; those ended the argument faster than another meeting would have.

Daniel Khoo Android engineer, Kuala Lumpur Mobile instrumentation audit
We came in with three names for the same wallet top-up. The mapping table was blunt about which two should die. Finance grumbled about the chart break in July. I would still rather have one name than a pretty history.

Meera Chandran Growth manager, e-wallet Event taxonomy rewrite
Before we shipped the new onboarding, they walked the RC on both stores and found transfer_confirm firing twice on Android 14 when the confirmation sheet was rotated. We held the rollout a day. That was the entire engagement, and it was the right size.

Hafiz Abdullah Founder, remittance app Pre-release tracking check
Aisyah stopped us putting forty events on the first version of a tuition-booking flow. We left the room with nine names and owners. I did not enjoy being told no in front of my engineer. The plan still sits in our repo.

Joanne Yap Product owner, education app Measurement plan session

Two engagements at length

A smartphone showing a colourful mobile interface

Mobile instrumentation audit

Checkout in a WebView, then silence

Regional fashion retailer, iOS and Android

The retailer had moved checkout from native screens into a WebView so that promotions could be edited without a store release. Native add_to_cart events still fired. checkout_complete did not, except for a small set of users who somehow still hit an old native path.

We walked a full purchase on both stores with a proxy. The WebView loaded a page that posted a purchase to the website's analytics property, which the mobile team did not read. The app SDK never received a bridge call. The measurement plan still listed checkout_complete as a mobile event.

The finding was not that WebViews are forbidden. It was that the plan and the bridge had drifted. Engineering added a single message from the page to the app after payment success, with order_id on the payload. We checked a later RC as a pre-release pass. The event was present on both stores.

Three colleagues talking over laptops at a table

Measurement plan session

A new onboarding, nine events, one owner each

Tuition booking app, first public version

The team had a Figma file with sixteen onboarding screens and a Slack thread of event ideas. They wanted a plan before the first store submission. We spent three hours on video, starting from the three questions they actually ask on Mondays: did a parent finish onboarding, did they request a tutor, did they pay a deposit.

We refused screen-view-for-every-frame. The written plan named nine events, each with a trigger ('after the request is accepted by the API', not 'on button tap'), and an engineer owner. Malay labels were added in a column for the weekly email; the event names stayed in English to match the SDK.

They came back four months later for an instrumentation audit of the shipped app. Seven of the nine events fired as written. Two had been attached to button taps during a crunch week. That is a smaller repair than an unplanned catalogue of forty.