Procurement Express
I design, instrument and ship product changes inside a live procurement platform, then check whether they actually changed behaviour.
ProcurementExpress is the kind of product I like: a lot going on under the surface. I work out what actually needs changing, build it into the product, and stay long enough to see what happened.
The work starts before the screen
A customer request is rarely a specification. I trace the current behaviour through the product and codebase, work out what the request is actually asking for, find the smallest useful scope and define the edge cases before anyone starts building.
That has taken me across approval routing, supplier filtering, invoice approvals, imports, budgets, QuickBooks fields and the small state-management details that decide whether a procurement workflow holds together. Sometimes the answer is new UI. Sometimes it is preserving a filter correctly after Apply. Sometimes a small request reaches across permissions, accounting data and long-standing Rails behaviour.
I stay with the work through tickets, implementation, automated tests, review-app QA and production follow-up. There is much less handoff when the person designing the behaviour can also inspect and change the product.
- Scope against realityI use customer feedback, existing product precedent and the codebase to define what should actually change.
- Build where it makes senseI work directly in the React/Capacitor app and the Rails product, alongside the engineering team.
- Verify before calling it doneI stay through PR review, regression coverage and manual QA.
Define value before measuring it
I defined mobile activation around participation in a real purchase workflow rather than installs: identify an approver, create a purchase request or approve one. That gave the measurement work a product question worth answering instead of a generic onboarding funnel.
I built the measurement plan around Firebase/GA4 and BigQuery, then wrote and ran the queries myself. Part of the work was tightening the event tracking so it could answer that product question before anyone tried to improve the funnel.
- Auth RecoveryTurn login and signup errors into clear next steps, while proving the Firebase-to-BigQuery measurement loop worked end to end.
- Invite Approver + First POMake the approval decision explicit and distinguish a real submitted PO from vague onboarding completion events.
- Phone Capture QualityMeasure whether the phone data collected during onboarding was actually usable, not merely present, then design the Android-first recovery path around that evidence.
The design went into the product
The mobile work went into the React and Capacitor application. I specified event contracts and guardrails, scoped implementation tickets and followed changes into the codebase.
The same is true on the web product. ProcurementExpress is an established Rails application with years of behaviour underneath it, so apparently small changes can cross controllers, models, policies, query objects and JavaScript. I trace that complexity early and let it shape the design.
AI-assisted development helps me move through a large codebase faster. More importantly, it lets me go from product question to code evidence to a tightly contained PR without losing the reason the change exists.
The work continues after launch
I set the decision criteria before launch, then produced 14- and 28-day readouts from the actual data. The point was never to make the work look successful. It was to decide what the evidence supported next.
That keeps hindsight out of the decision. A change can move the right behaviour and still not deserve another round. If it clears the bar, we keep going. If it doesn’t, I change direction.
This is the loop I care about: build the right thing, measure the right thing, then make the next call without protecting the work just because I made it.
- Instrument before optimizingEvent definitions were tightened before any funnel number was used to make a product decision.
- Decide before readingSuccess criteria are set before launch, so the result does not get reinterpreted afterwards.
- Ship, read, decideThe work continued through production measurement, not just implementation.
9.75%invite rate at Day 28, up from a 0.8% baseline — still Not validated: under the 10% floor set before launch
84.09%of users who chose to invite an approver sent the invite — the form was not the blocker
+2.6ppAuth Recovery lift over 14 days — too small to call meaningful, so not claimed as activation
- The most useful thing I bring to a product is a shorter distance between what we think is happening, what the product actually does and what the evidence says we should do next.