Loop — From Proposal to Paid, Without Six Apps in Between

Every freelance designer I've spoken to runs client work across the same scattered set of tools: email for the proposal, a Figma link for the work itself, Slack or email again once feedback starts, a Google Doc for notes nobody re-reads, and a separate invoicing app to actually get paid. Loop is my answer to that: one narrow, opinionated tool that does the whole loop, rather than one more all-in-one platform trying to do everything.

This case study covers the full pass end to end — competitive research and personas, information architecture and user flows, a wireframe stage, a hi-fi Figma design system, and a second pass that rebuilt the same product as a working React app on shadcn/ui and Tailwind, re-themed through Figma variable modes rather than as a second, parallel design system.

Feedback gets scattered across threads instead of pinned to the work itself. Revision rounds quietly run past what was scoped and agreed, because nothing is counting them. And invoices go out late, because nothing tells the freelancer the moment work is actually approved. None of these is a single missing feature — they're what happens when a relationship spans five disconnected tools and nothing owns the handoffs between them.

Nothing in the market combines structured, limited-round feedback with escrow-style protected payment for independent freelancers working directly with their own clients. That gap is Loop's whole reason to exist.

Design principle set from day one: the freelancer gets a full tool; the client only ever sees what's waiting on them, reached through a magic link, no password required.

The freelancer app has 6 top-level sections — Home, Projects, Messages, Clients, Money, Settings — plus Insights on desktop only. A project drills into three sub-views: Milestones, Review (with pins and version compare), and the proposal itself. The client side is intentionally flat: one page listing everything currently waiting on that client, reached by magic link, no account required.

Route map: Auth: sign-up, check email, onboarding, log in, forgot password, reset password, two-factor code. App shell (Home, Projects, Project detail, Messages, Money, Clients, Insights, Settings) sits behind the sidebar/tab-bar layout; the proposal builder and the review screen are deliberately full-screen and outside it, since both are focused, single-task flows. Client portal: proposal (sign & pay), signed confirmation, review, and files-delivered. Plus a reference page listing all 34 notification emails the product sends. 23 routes in total.

The magic link is what makes the client side possible without an account. Below is that handshake end to end: Tom opens the link from his email, Loop validates a single-use token scoped to that one project, and only then does the portal render — with the loop closing back to Loop itself the moment he signs and pays.

Once Loop DS v1 was validated in Figma, the question became how to get it into code. Rather than hand-building a bespoke component library from the Figma files, Loop's components are shadcn/ui's own primitives, re-themed through one shared variable collection — same Radix UI foundations underneath, same component APIs, same file structure a shadcn user already knows. Any frame or app instance set to "Loop light" or "Loop dark" re-skins every button, badge, input, sidebar and table to Loop's brand, with nothing manually recolored.

Interaction principles, carried from the hi-fi design system into the coded rebuild: One next action · Status in words, never color alone · No surprise costs · Undo over confirm · Content before chrome on mobile

Rendered live below, in the browser, from the same token set the app itself uses — not screenshots of the Figma file.

This was built end to end by one person, so these are reasoned decisions rather than ones validated against real client and freelancer usage yet — that's next (see Reflection below).

A walkthrough of the four moments that matter most in Maja and Tom's relationship: the freelancer's home base, sending a proposal, getting paid, and the client's side of that same transaction.

The dashboard leads with what's waiting on Maja rather than a generic activity feed: overdue invoices, milestones awaiting client approval, and unread messages surface above anything already in a healthy state. Status is always shown in words next to a colour (“Waiting on Tom — 2 days”), never colour alone, so the screen stays legible for a colour-blind user too.

Every proposal is built as a sequence of priced milestones rather than one total, because that structure is what later powers partial funding, partial approval, and per-milestone disputes. The builder reorders milestones by drag, shows a running total as they're added, and validates that the sum matches the quoted project value before it can be sent.

The highest-stakes screen in the product, so it says exactly what will happen before it happens: which milestone is funded, how much is protected, and what button press releases it. “Approve & release €1,200” instead of “Confirm” is applied at its strictest here, since it's the one place in Loop where a misread label has a financial consequence.

Tom opens a link from his email and lands directly on the proposal, already scoped to that one project, with no login screen in between. He can comment on individual line items, then sign and pay the deposit from the same flow, on his phone, in the gap between meetings — the specific failure mode the original research identified: clients who intended to review a proposal “later” and never did, because later meant finding a password.

Loop is, at heart, an argument that the fragmentation freelancers deal with — a proposal tool here, an invoicing tool there, a separate place to chase a signature — is a design problem as much as a product-scope one, and that the fix is an opinionated, narrow tool rather than one more all-in-one platform. Carrying that argument from a problem statement through validated flows, a real design system, and a working coded prototype — rather than stopping at high-fidelity mockups — was the point of building it this way: a decision like “clients get a magic link, not an account” only really proves itself once it's a link that opens, on a phone, in an actual browser.