Case study · Fintech marketplace
PENDFUNDS
The money only moves when the deal does.
An escrow, a mediator, a marketplace and a reputation system in one product — for deals that happen on the platform, and for the ones that don’t.
- Client
- PendFunds
- Role
- Product design — UX strategy, UI, design system
- Platform
- Web app + admin portal
- Year
- 2024

Nine states — one transaction
The problem
The transactionis the risk.
Whenabuyerpaysbeforereceivingaproduct,bothsidesareleftwithaproblem:
The buyer
Doesn’t know if they’ll receive what they paid for.
The seller
Doesn’t know if they’ll actually get paid.
PendFunds was designed to sit in between — holding the payment in escrow, structuring the transaction with contracts, and releasing funds only when the agreed conditions are met.
Fake goods, vanished sellers
Descriptions that don't match. Payment sent, seller gone. A delivery that never arrives and nobody to escalate to.
Chargebacks and false claims
Fraudulent chargebacks. Claims of non-receipt. Work delivered, then disputed. Buyers who vanish the moment they have the goods.
The deals that never happen
Both sides are behaving rationally. Both sides lose. The market quietly shrinks to people you already know in person.
Understanding the business
This was nevera UI project.
Asked for
An escrow app.
Actually required
A secure bridge between both sides, handles disputes fairly, keeps track of who can be trusted, helps bring buyers and sellers together, and makes money from each transaction — all without making the process feel complicated.
Protect both parties
Not just the payer. A platform that only refunds buyers teaches sellers to take the deal off-platform.
Resolve disputes with evidence
Not with chargebacks, and not with an automatic refund that punishes whoever is slower to complain.
Measure trust objectively
Not with stars. A number derived from what actually happened, that no one can write their way into.
Bring your own demand
A marketplace, not just a tool. An escrow you have to remember to use gets used once.
Monetise seven ways, invisibly
Every revenue stream designed in from the start — and none of them allowed to make the interface feel like a toll booth.
Two people, opposite fears
Emily
BuyerThe savvy shopper
Wants
Find good products at fair prices, and know her money and details are safe.
Afraid of
Fraudulent sellers and fake products. Payment systems she doesn't trust. Platforms where a complaint goes nowhere.
David
SellerThe entrepreneurial seller
Wants
Grow sales, and be visibly credible to buyers who have never heard of him.
Afraid of
Chargeback fraud and false non-receipt claims. No reliable dispute process. Nowhere that treats seller protection as a feature.
Their fears are mirror images, and neither can be fixed by reassuring the other. That symmetry is why the product ended up with an escrow, a mediator and a score rather than just a payment button.
Design strategy
Not seven modules.Five questions.
Nobody has ever asked to initiate an escrow contract with structured mediation. They ask whether they're about to be robbed. Reframing seven modules as five questions is what made the product explainable in under a minute — and it became the structure of this case study too.
Is my money safe?
It goes to PendFunds, not to the seller — and it only moves when you say the work arrived.
Has the other person delivered?
The contract says what is happening right now, in one word that both of you can see.
What happens if something goes wrong?
You report it, and the money freezes exactly where it is until someone neutral has looked.
Who decides if we disagree?
A person at PendFunds reads both sides, then returns the money, releases it, or splits it.
Can I trust this person?
A score built only from deals they actually finished. Nothing about it can be written by them.
The contract
Answers Q1Before any money moves,there’s a document.
Escrow gets the attention, but the contract is what makes escrow adjudicable. Every piece of evidence a dispute needs three chapters from now — what was promised, for how much, by when, and what counted as done — is created on this screen.
Terms, not trust.
Parties, item, amount, deadline — and the field that matters more than the other four: what “done” means. Written down before anyone is owed anything.
Pending until both agree.
Nothing is chargeable until the other side accepts. A contract one person wrote alone isn't an agreement, and the status says so — to both of them.
Works off-platform too.
One share link, one receiving party. The deal can have happened in an Instagram DM at 2am — the contract still exists, and so does the protection.
Contract · 4322144322
Pending
Accepted. Two people who have never met now have the same sentence in front of them.
The escrow
Answers Q1The money arrives.Then it waits.
This is the only chapter that inverts, because this is the only moment the whole product exists for. Every other feature is arranged around keeping one number still.
Stripe first. Then a contract.
You cannot create a contract until your Stripe account is connected. The rails are in place before there is any money to move — so the only open question is ever when funds are released, never whether they can be.
Then it stops.
The money reaches PendFunds and goes no further. The seller sees the exact amount, confirmed and waiting, and cannot withdraw a cent of it. That visibility is what makes them ship.
The buyer decides when.
Confirmation is the only thing that moves it. Not a timer, not support, not the seller — which is why the buyer never has to trust anybody to get to this screen.
Held in escrow
$0.00
Available to seller
$0.00



The lifecycle
Answers Q2One transaction.Eight moves.
Everything so far has been about the money. This is about the other half of the question — whether the thing you paid for actually turned up, and how two people who can't see each other stay in agreement about that.
- 01Product chosen
- 02Contract generated
- 03Buyer pays
- 04Held in escrow$550.66 held
- 05Seller fulfils
- 06Buyer receives
- 07Buyer confirms
- 08Payment released
chosen
generated
pays
escrow
fulfils
receives
confirms
released
The money reaches step 04 and stops. Steps 05, 06 and 07 all happen while it sits there — and only step 07, the buyer confirming, can move it again.
7b · The branches
When it doesn’tgo to plan.
Five deviations, four of which return to the main line. Designing them as states rather than as support tickets is the difference between a product that handles failure and a product that emails you about it.
Contract · 4322144322
Drawn from the status spec · no screen was exported in this state
The deadline passes.
Nobody has to complain for the system to notice. The state changes on its own, which means the buyer doesn't have to decide whether they're being unreasonable yet.

Ask for time, not forgiveness.
A seller running late has one designed alternative to going quiet: a reason, in writing, capped at a hundred words. Going quiet is the behaviour the state exists to replace.

The other side gets a decision.
Not a notification — Accept Request or Reject Request, with the proposed new deadline printed beside the old one. The seller can ask for anything; only the buyer can grant it.

Escrow freezes.
Neither party can move the money, including PendFunds, until mediation resolves. The freeze is what makes an honest process possible — nobody is negotiating against a deadline.

Even ending it needs consent.
Nobody walks away unilaterally. A cancellation is itself a request the other party has two days to answer, and only then do funds return to the buyer and the contract close.
Nine states. One of them is the one you were hoping for.
The happy path
Everything else
Chat
Every Contract HasIts Own Chat
The thread lives inside the contract, not beside it. Not for convenience — because when a dispute opens two chapters from now, the conversation is already filed as evidence against the agreement it belongs to.
A separate inbox would have thrown away the most useful record in the product.

Mediation
Answers Q3 + Q4A dispute isn’t an argument.It’s a filing.
Every escrow product can hold money. Almost none of them can tell you what happens when two people disagree about whether it should be released — the honest answer is usually an automatic refund, which just moves the loss onto the seller.
Nobody is asked tobuild a case.
Three of the five things a mediator needs already exist by the time a dispute opens — because the contract, the chat and the delivery proof were all created inside the transaction. The user points at a case rather than assembling one.
The contract
Already on fileTerms, amount, deadline, definition of done
The chat thread
Already on fileEvery message, already scoped to this contract
Delivery proof
Already on fileTracking, handover, timestamps
Written explanation
Each party's account, submitted separately
Documents & screenshots
Whatever else either side wants on the record



A different room,a different job.
The buyer’s interface is built to reduce anxiety. The admin’s is built for throughput — a queue, both submissions side by side, and a decision that has to be defensible to whichever party loses. The surface changes on purpose, because pretending these are the same user is how internal tools end up unusable.
Mediation is a staffed process. Designing it meant designing for the staff, not just for the aggrieved.



Trust Score
Answers Q5Trust You BuildThrough Transactions
Reviews are gameable, subjective, and written almost exclusively by people who felt strongly enough to type. A number derived only from transaction outcomes can't be flattered, bought, or brigaded — and it means a new seller has a path to credibility that doesn't involve asking friends for five stars.
Moves it up
- +Contract completed
- +Delivered before deadline
- +Dispute resolved in your favour
Moves it down
- −Dispute lost
- −Contract cancelled by you
- −Deadline missed
The loop
A tool gets used once.A loop keeps going.
An escrow you have to remember to use is a browser bookmark. Putting discovery inside the same product as the protection is what turns a single cautious transaction into a habit — and it's the difference between a utility and a platform.
- 01MarketplaceDiscovery
- 02ContractTerms agreed
- 03EscrowFunds held
- 04CompletedReleased
- 05Trust ScoreReputation earned
- and back to the top — each turn produces a fee, a score, and a reason to return.
Design system
Financial softwarethat isn’t frightening.
Trust, security and professionalism — without looking like a bank, a law firm, or anything a first-time seller would close the tab on. Built on Flowbite and extended where the product needed vocabulary the library doesn't have.
Say where the money is
Never “processing”. Held, by us, until you say otherwise — with the amount, in the same view as whatever action comes next.
One state, one colour, one word
Nine statuses, nine colours, one component. A transaction is never ambiguous and never described two different ways.
Plain language over accuracy
“The contract has not been accepted yet” beats “awaiting counterparty attestation”, even though the second is more precise.
Symmetry between parties
Buyer and seller see the same state, the same word, the same tense. Divergence is where disputes are born.
The status palette
Contrast measured on #FAF9F6 · all ≥ 4.5:1
Nine colours doing the product’s hardest job. They’re all darkened from their obvious versions — a warmer amber and a brighter orange both read better and both failed at chip size, and chips are the smallest type in the interface.

Happy path
Happy path
Happy path
Happy path
Branch
Branch
Branch
Branch
Branch
Brand indigo, split three ways
Display / fills
#4A38C4 · 7.52:1
Small text / labels
#4132AE · 8.70:1
Decorative glow only
#6D5BFF · 4.34:1
The vault (dark chapter)
#0D0A2B · —
Pushed toward indigo from the sampled brand purple, so it reads as PendFunds rather than as this site’s own accent.
Type scale
Display
Bricolage Grotesque · 600
Body
Geist · 400
Meta
Geist Mono · uppercase, 0.16em
Accent
Instrument Serif · italic
Non-negotiables
Component library
Flowbite, extendedStatus component
1 chip · 9 statesBalance display
Always a pair — held / availablePortals
2 — user app and adminOutcome
What the designmakes possible.
PendFunds was designed to be commercially viable, not just usable — so the honest measure of the work is what the product is now structurally capable of doing.
0
Transaction states designed
0
Revenue lines designed in
0
Dispute outcomes, not two
0
Portals — user and admin
Design facts. Performance figures pending from the client.
Both sides have a reason to stay
Escrow protects the buyer; mediation that can split the money rather than only reverse it, plus a freeze that binds PendFunds too, protects the seller. A platform that only refunds buyers loses its supply side, and supply is the harder half of a marketplace to acquire.
Monetisation the user doesn't resent
Seven revenue lines, none of them on a screen that exists only to collect them, and the largest of them charged after the buyer already has what they paid for. Fees positioned this way survive a competitor who undercuts them.
Completion is the path of least resistance
Late, Extension and Request Opened exist to catch a transaction before it dies of silence. Four of the five deviations return to the main line — every one that does is a fee retained and two users who transact again.
A marketplace’s product isn’t the listing. It’s the certainty that the listing will be honoured.



