I led the end-to-end design of PayCargo's first mobile app, from scratch. AP teams approve payments from the road; truckers, drivers, and field operators pay on-site the moment cargo is ready at the terminal or warehouse. PayCargo finally runs where the cargo does.
PayCargo's web product served the AP manager at her desk. But freight doesn't run from a desk, and a whole group of users (truckers, drivers, field operators) never sat at one. Until the carrier gets paid, cargo sits at port racking up demurrage by the hour.
Three signals made the mobile case undeniable: 47% of web sessions started on mobile (and abandoned within two screens), an entire user segment couldn't use PayCargo without a laptop, and 18% of weekly support tickets contained phrases like "on the road," "at the terminal," or "couldn't get to my computer." The opportunity wasn't "PayCargo, but smaller." It was building the tool for the person standing next to the cargo.
With no existing mobile product to evaluate, I ran three research tracks in parallel: competitor analysis (how the job is solved on competing apps), in-house analytics on PayCargo's mobile-web traffic, and contextual interviews with AP teams, drivers, and field operators in their actual environments. Nothing made the roadmap unless all three pointed at the same friction.
I audited (a) freight and logistics mobile apps (CargoWise, Flexport, CargoSprint), (b) approval-workflow apps in adjacent B2B fintech, and (c) field-operative apps from outside fintech (ServiceTitan, Onfleet) to understand how mobile patterns translate to high-stakes, time-sensitive, professional contexts.
The output: a what to adopt, what to reject, what to invent map ranked by relevance to the cargo job.
Even without a mobile product, the demand signal was already in our data. I ran segment analysis on web users by device class, pulled abandonment funnels for mobile traffic, and worked with Customer Success to tag and surface support tickets that mentioned mobile or field contexts.
Within a week we had quantified evidence that 47% of users were already attempting the job on phone, and bouncing.
For the desktop case, interviews validated hypotheses already shaped by data. For this project, interviews were the primary evidence. I ran 14 contextual interviews across truckers, brokers, dispatchers, and AP managers, with a mix of at-port visits, on-site walkthroughs, and ride-alongs.
The question that unlocked everything: "Walk me through the last time you needed to do something PayCargo-related and weren't at your desk."
Three patterns showed up across the audit, the analytics, and the interviews. The triangulation separated real opportunities from a feature wishlist.
One session set the direction for mobile. PM, Engineering, CS, and Sales in the room, with one required output: a Job-to-Be-Done specific to mobile that every feature would later have to defend itself against. Without it, the product would have drifted into "desktop, smaller."
That framing made the MVP cut obvious. Mobile wasn't desktop made smaller. It was the on-the-ground payments device. Every proposed feature had to clear the 90-second test, and anything that didn't help close that loop shipped in v2.
The workshop output split into two different bets, same JTBD with different scope. Both went to mid-fi for a usability round before we committed to high-fidelity.
Click any option above to expand. Option B cleared the 90-second test in round-1 usability and became the foundation for high-fi.
Before high fidelity, four mobile-specific principles drove every screen: one-handed by default (primary actions in the bottom thumb arc), glanceable over comprehensive (answer from the notification when possible), offline-tolerant (cached state + optimistic UI, since ports have terrible connectivity), and biometric-first auth (Face ID / Touch ID, never password every time). Two Maze + UserTesting rounds followed, one on iOS and one on Android, sized to validate the 90-second test and surface platform-specific patterns before production.
A focused MVP shipped on iOS and Android. Three surfaces, each one chosen because it cleared the 90-second test: open the app, finish the job, get back to work.
iOS and Android home-screen widget showing pending payments, recent releases, and cargo status. Push notifications only fire on state changes that actually matter (released, blocked, payment-required), so the user isn't pinged for every backend event.
Searchable vendor directory tuned for the gate: airline prefix, station, or carrier name with a country filter. Lightning-marked frequent vendors float to the top, so repeat-pay flows take one tap instead of five.
Bottom-sheet payment selector with available balances inline, so users see what they can spend before they commit. PayCargo Finance, Overnight Debit, and Credit Card each show processing fees at the moment of choice instead of on a confirmation screen.
Two columns of muscle memory: the patterns that fought us in this 0→1 mobile project, and the ones that compounded enough to bring forward.
