The agreement is the easy part. Everything after it should be too.
A private workspace where two people set the scope, hold the money, and get on with the work.
01Why it exists
Freelance work mostly runs on good faith, and mostly that is enough. Two people agree on what is being made, what it costs and when it is due, and then they get on with it.
What is missing is anywhere for that agreement to live. A contract describes it. An invoice follows it. Nothing actually holds it. So when scope grows or a payment slips, both people fall back on memory and goodwill, and the cost lands on whoever is least able to absorb it.
"A contract describes an agreement. Something still has to carry it out."
02Research and strategy
Holding other people's money is not something you can ship and iterate on, so that is where the research went. I compared more than sixteen conditional fund holding providers on licensing, who carries the money transmitter burden, cross border coverage, real pricing rather than headline pricing, and how holds and releases actually work. Seven payment providers were assessed separately.
I built two fee calculators to model the economics. A five percent fee capped at two hundred and fifty dollars only works if the provider's cut leaves a margin, which settled the shortlist on its own.
Positioning came down to one distinction. Marketplaces bundle finding someone with protecting the work, and charge for both. This sells only the second half, to people who already found each other.
There was no user research. No interviews, no surveys, no usability testing. The thesis rests on five years designing payment, transfer and lending products, and on having freelanced. That was a deliberate allocation, and the reasoning is in the last section.
03What made it hard
No brief means no constraints arrive for free.
A deadline, a budget and someone who says no all arrive for free on client work. Working alone, none of them do, so I had to build my own.
The scope was enormous for one person.
Identity checks, scope lock, change orders, contracts, the Vault, milestones, delivery verification, chat, scheduling, disputes, an audit trail. Each one earns its place as trust infrastructure. Together they were far too much for a first version, so mobile, multi seat accounts and full multi currency moved to later.
Regulated money is a hard wall.
The provider decision depends on things I do not control: which countries are covered, whether foreign exchange sits inside the headline rate, and whether a pre-revenue account gets approved at all. Cross border had to work from day one, since the two people are often in different places.
Trust has to start somewhere.
A product whose whole value is that you can trust it with money has to earn that from people who have never heard of it. That is why the provider choice moved toward the one with the most recognizable backing rather than the most elegant integration.
04Design decisions
1. Invite only, two parties, not a marketplace
Rejected: profiles, browsing, bidding, matching.
Most working relationships start with a referral or a message, so the finding is already done. Cutting discovery removes the cold start problem entirely and keeps the fee small, because the platform is not being paid to introduce anyone. Either side can send the invite, which makes this a shared tool rather than a freelancer tool clients put up with.
2. The word Vault, never escrow
Rejected: the industry standard term.
Escrow is accurate and institutionally cold. It sounds like a closing, like something a lawyer administers. Vault is plain and concrete, and it works grammatically everywhere the mechanic appears: add to Vault, in Vault, protected funds, approve and release. Those strings are locked, because the language is the interface for the mechanic.
3. Payment releases on its own if approval does not come
Rejected: holding funds until the client actively approves. Also rejected: routing every silence into manual dispute resolution.
Waiting should not cost the person who did the work. A release timer turns an open question into a predictable date that both people can see from the moment work is submitted. Dispute resolution is still there for genuine disagreement, which is a different thing from someone being busy.
4. Scope locks at start and grows only by addendum
Rejected: an editable brief. Also rejected: informal change requests in chat, which is how it works everywhere else.
Scope grows for good reasons. It just needs to grow visibly, so that an addition is priced as an addition rather than absorbed quietly by one side. Each addendum carries its own time and money, needs both signatures, and its funds go into the Vault before that work begins.
5. Watermarked previews before release, clean files after approval
Rejected: handing over real files and then asking for payment. Also rejected: requiring approval before the client sees anything.
Delivery asks someone to go first, and whoever does is exposed. A watermarked preview means nobody has to: the work can be judged in full while the file is not yet usable, so approval and release happen together.
6. A rigid, deliberately boring design system
Rejected: an expressive interface. Specifically rejected: gradients, shadows, any tint or lightened version of the accent, and odd numbers anywhere in the system.
For the person using it, restraint reads as competence in a way personality does not, so color carries state rather than decoration. The lime accent stays in the brand layer and never enters the working app, which keeps status colors unambiguous. For me, working without a design reviewer, even numbers only across radius, type and spacing makes drift visible without judgment. A thirteen pixel value is simply wrong on sight.
05The product end to end
The decisions above are the interesting part. The rest is the ordinary surface area, which has to hold the same line.
Setting up a project
Five steps, in order, before work starts or money moves.
The working day
Where the time actually goes once a project is running.
When something changes
The states that matter most.
The account layer
06Where it stands
Designed end to end and built out as a clickable prototype. The auth and onboarding flow, project workspace, scope, contract and Vault interfaces are all designed and clickable. None of it is wired to a backend, and no money has moved through the Vault. The payment provider is chosen and not integrated, with the selection still conditional on three open questions about foreign exchange, local rails coverage, and whether a pre-revenue account gets onboarded at all. No users, no revenue, no pilot.
07What I took from it
Research effort should follow irreversibility, not interest. The design system was locked in a session. The money partner took three research sweeps and is still not final. Color can be changed on a Tuesday. A payment partner cannot.
The edge cases were the product. The happy path is trivial: fund, work, approve, release. All the hard thinking went into what happens when someone is slow to reply, when scope grows, when revisions run out. In a trust product, that is the whole promise.
Vocabulary is a product decision. Choosing Vault over escrow and then locking the exact strings changed how the mechanic could be built and explained. Owning product, design and language at once makes that consistency available in a way it is not on a team.
Constraints have to be manufactured when none arrive. Even numbers only, three type weights, no gradients, one word for the mechanic. None of those were aesthetic preferences. They stood in for the reviewer who was not there, and arbitrary rules work precisely because they are checkable without judgment.
Good faith deserves a mechanism.