Getting sellers paid tomorrow, not next week.
- Role
- Senior Product Designer (Design Lead)
- Timeline
- H1 2026
- Working with
- Product Manager, Content Designer, User Researcher, External partners
- Status
- Live
The short version. Back Market’s first embedded financing product: next-business-day payouts, funded by a partner, designed not to read as debt. I owned the experience end to end — design, coded prototype, launch. Designing the full lifecycle from the outset, rather than a signup pitch, is what turned interest into execution.
Outcome Adoption 14% → 22% by week 13
Back Market sellers wait about seven days to be paid after a sale. For smaller and growing sellers that delay locks up working capital they would otherwise spend on stock, the biggest lever on how fast they can grow. Slow cash is a growth ceiling and a retention risk.
Standard payout
a week of working capital, locked up
With BackFunds
BackFunds closes that gap. A third-party partner funds the payouts, so Back Market carries no balance-sheet risk, and the whole product lives inside the seller Back Office, where it reads as a Back Market capability.
The design problem was harder than the pitch. Sellers don’t arrive looking for credit. The word “financing” carries baggage: debt, fees, being locked-in. The mechanics: how repayment works, what the balance means, what it costs, were either counter-intuitive or not yet pinned down. The aim was to make an unfamiliar financial product feel trustworthy and clearly worth it, inside a dense operational tool where sellers are thinking about orders and stock, not financing.
The prototype was the argument
This was a product that didn’t exist yet: the partner’s terms were still moving and several mechanics were undefined in the spec. So the design lead job was mostly reducing ambiguity into decisions the team could build against, then pressure-testing them with the partner and stakeholders.
The concept was built as high-fidelity coded screens in Claude Code rather than static Figma mocks, so stakeholders and the funding partner reacted to something close to the real product. The partner’s senior team ended up critiquing flows, not artwork. After a positive review, the project moved into phased technical planning.
It also made the numbers a design responsibility. Every figure in the prototype had to reconcile against one coherent money model; at one point the displayed outstanding balance implied a month of advances, impossible under a daily-advance, weekly-repayment cycle. I caught it and fixed the model. Unglamorous work, but it kept the prototype credible in exec and partner reviews.
Making a money product legible
The mechanics were the hard part. They run counter to how sellers expect financing to work, and several were still undefined in the spec.
The seller never wires money back: their early payout is repaid automatically when the normal weekly payout lands and routes to the partner. The “outstanding balance” in the spec is really the float of advances not yet settled, not money the seller owes. A UI that said “you owe a balance” would frighten sellers away from a product with no repayment burden. I worked the mechanics through with the PM, confirmed there was no arrears path, and distilled the answer into one hard rule.
Never imply the seller owes money. The product carries no repayment burden, so the UI must not manufacture one.
Never
Instead
“You owe 3,750 €”
“Balance left to clear: 3,750 €”
“Repayment due by Friday”
“Your payouts clear the balance automatically, nothing for you to do”
“Outstanding debt”
“Advances not yet settled”
Every balance, pause, and cancel screen holds to it: repayment is presented as passive and automatic, something that happens to the balance rather than something the seller must do.
Pause is the clearest example of designing the mechanics rather than the screen. The spec gated pause on a zero balance, but an active seller almost always carries a float, so pause would have been practically unreachable. Backwards.
I designed a scheduled pause: it stops new advances immediately, the balance winds down from incoming payouts, and the account flips to paused at zero. The backend constraint holds and the seller gets a control that works. Cancel follows the same shape, terminal instead of resumable.
Pricing ran into the same problem. The partner’s terms weren’t confirmed and exec feedback was explicit: no single daily fee before underwriting. Every cost and advance figure became a range (“500 to 750 euros a day, around 0.1% to 0.15% daily”) that brackets the working model without promising a number no one could stand behind.
Eligibility was a translation job. Internal risk-classification language became plain second-person reasons a seller recognises, so an internal quality-tier threshold turned into “consistently strong quality metrics: low defect and refund rates.” Internal language leaks onto customer-facing surfaces constantly, and catching it is most of the job.
Three calls that set the product direction
Own the value model
The Growth Simulator models what daily payouts are worth to a seller. I argued it should run on Back Market’s own data and computation rather than the partner’s API, and we chose a full-API integration over an embedded or SDK approach for the same reason. The partner’s calculator was built to sell. Sellers check these numbers against their own books, so the Back Office version had to be defensible line by line.
Owning the model also meant respecting the seller’s numbers. Gross margin sharpens the estimate but it’s commercially sensitive, so entering it is optional. Without it, the simulator gives a useful answer from account data Back Market already holds. With it, the seller gets a sharper one, and a plain disclaimer says the figure is used only for the calculation and never stored.
Show one provider, not a marketplace
The product can route a seller to one of several funding partners, and the eligibility engine already picks the cheapest fit. The spec called for a side-by-side comparison. I argued against it: the seller can’t beat the engine’s answer, so a comparison table only moves work onto them. The version that shipped shows sellers a single match, framed as “matched for you,” with full terms in plain sight.
Host servicing inside the Back Office
Partners normally hand the seller off to their own site after signup, which is also where they lose the most people. I pushed to host the full dashboard, pause, and cancel natively instead. It’s a deliberate departure from the partner’s standard model and a real maintenance cost, and product leadership signed off because native servicing is what keeps BackFunds feeling like Back Market rather than a redirect to a lender.
A lifecycle designed up front
A seller moves through a lifecycle, and a single signup screen only covers the first minute of it. Designing all five states up front (eligible, under review, action needed, active, not approved) made the entry point honest and reusable, and pulled product questions forward, like how “not approved” should feel: calm, not an error. Each state maps to a semantic token in the design system, so colour does the signalling. Only “action needed” gets a loud primary button.
The banner went through the same discipline. Version one led with the product and read like an advert. The chosen version leads with the outcome, “Get paid tomorrow, not next week,” anchored to the seller’s real next payout amount and date.
What launch showed
BackFunds shipped to eligible sellers as a native part of the Money and Wallet page, with a microservice replacing the earlier manual operations.
- from 14% to 22%
- Adoption among eligible sellers at week 13, against a 30% year-end target
- under 7 days
- Seller onboarding, down from 2–3 weeks
- about 2×
- Revenue against the programme’s original plan, tracking at week 13
- under 5%
- Of dashboard-answerable questions reached support
Adoption among eligible sellers
Adoption across the first quarter after launch, as relative shares of eligible sellers.
The gap between “interested” and “activated” is the number that tells you whether the design is working rather than the offer. Framing the value at the moment of payout, and designing the whole lifecycle instead of a signup pitch, is what closed it.
The support number says the same thing from the other direction: servicing questions stopped reaching humans, which means the balance, pause, and lifecycle states were explaining themselves. Hosting all of it inside the Back Office is what made that possible, and it is the call I would defend hardest if we ran the programme again.