← All work

Apron mobile: paying suppliers on the go

Payments in the Apron app, so business owners can pay suppliers on the go.

Company
Apron
Year
2026
Team
Design, PM and Mobile engineering

My role

Led product design: platform strategy, scope, end-to-end design, components, and beta release

Outcome

  • Over £1m paid from the app since launch
  • 272 companies have paid from the app since it launched in June 2026
  • Over a third of them were new to Bill Pay
Supplier view with outstanding billsEntering the amount on the custom keypadReview and pay with Amex, including the card feePayment confirmation
Pick a supplier, enter how much to pay, done.

Problem

Apron’s mobile app was only for capture: snap a receipt and Apron reads it. Paying suppliers and staff happened only on the web. Customers kept asking to approve and pay on the go, and about 15% of payments were already made on mobile web.

  • Mobile web was a workaround. Adapting a desktop-first product to a small screen would always feel average. The app could use what phones do best: Face ID, the camera, staying signed in.
  • The app was already on people’s phones. Many people used it only to capture receipts, and were already signed in. Payments there could bring them into Bill Pay.

Solution

Payments in the mobile app, built around the supplier. Pick a supplier, pay a bill or send money without one, choose how to pay, and it’s done.

Key decisions

  • Not everything belongs on mobile. The first instinct was to bring everything from desktop to the app. I pushed back. Early on, I turned the team’s conversations into a written strategy for the app that kicked off the project. It defined which jobs fit mobile, like fast, focused payments and approvals, and which stay on desktop, like payroll and approval workflows. This became the direction for the app.
  • Approvals or payments first. Customer feedback asked for both, so I proposed starting with approvals: one of the most crucial moments in their workflow, and a more contained scope. The PM proposed payments, a strategic bet on revenue with a bigger scope, and we agreed to start there.
  • Simplify every call. The bigger payments scope made one principle run through every call: simplify. To do it safely, I had to understand how the whole payment platform worked, and Claude Code was crucial for digging into the code. We cut far more than we kept. For example, the app offers only Open Banking or card, with no transfer through Apron. It keeps only the validations that make sense for these payments. And V1 supported GBP payments only, leaving things like international and batch payments for later iterations.
  • Supplier first, not bills first. Web starts from bills, but customers think in suppliers, and mobile was the chance to build around that mindset. 84% of payments made on mobile web were for a single supplier, so the app leads with suppliers.
Platform strategy: desktop for deep work like payroll, mobile web as the flexible fallback, and the app for fast, frequent tasks like paying a supplier
Which jobs belong in the app, compared with desktop and mobile web today.
Figma Make with the prompt chat on the left and the clickable keypad prototype on the right
Early ideas and variants prototyped in Figma Make.
Supplier view with outstanding billsA bill's detailsEditing the bill amountChoosing the bill currency
Supplier first: pick a supplier, then confirm or change any bill, so people stay in control of what they pay.
Adding a new contact with their bank detailsThe payee check confirming the account name matched
Payee checks give people confidence they're paying the right person, which matters even more when paying on the go.
Payment details for a payment without a billPayment details for a bill payment, with the bill detailsPayment details for a bill paid by Amex as part of a batch payment, with fees
One payment details view for anything paid on web or in the app, from a single payment to one paid on web as part of a batch.

How I led it

I led product design, working with a PM and two mobile engineers, and directly with the CEO.

  • Designed for a unit of one. I anchored the design on one existing customer who stood for our core users: business owners who aren’t very tech-savvy, are always on the go, and fit payments in between everything else.
  • Kept the complexity under the hood. A simple flow hid a lot: bills to confirm, payee checks for new contacts, payment method validations, card restrictions like Amex’s, payment states, and payments syncing both ways between web, app and accounting apps. People also arrived from different places, from capture, from web, or new to Apron. I reused existing flows where I could and created new components for the app.
  • Carried it to release. I drove the release from a plan I wrote, covering beta feedback, QA, rollout, comms and support. I owned QA and the beta: test cases across iOS and Android, many rounds of testing, and a beta with session recordings and live onboarding calls. Feedback was positive, and only small fixes came out of it.
  • Working with AI. AI is part of my everyday workflow. I started by prototyping ideas in Figma Make to explore them quickly, before moving to high fidelity. I used Claude Code to go through the codebase and find every validation web runs today. I also built working prototypes with Claude Code, like batch payments, and automated their walkthrough videos for engineers.
Validation and message map for the payment flow, showing contact and beneficiary checks such as Confirmation of Payee. The full map lists every case, with those cut from V1 struck through
Mapping every validation web runs today with Claude Code, then choosing what the app needed.
Batch payments, prototyped with Claude CodeTry it

Outcome

The app launched in June 2026, and 272 companies have paid from it since. Over a third of them were new to Bill Pay, so the app brought in new payers, not just moved existing ones. Since launch, over £1m has been paid from the app. Wallet payments have since come to the app too.

Reflection

Simplifying was the principle behind every call, and it held up: people didn’t need everything web does to pay on their phones. What I’d do differently: with so many cases to cover, QA took many rounds. Next time I’d use AI to automate those checks myself, from the start.