Vabble
Fintech platform turning the receivables of emerging-market exporters into immediate liquidity. Founding frontend team member across every iteration — a three-person team, a hand-built design system and genuinely hard business logic.
- Role
- Frontend — Antártida
- Period
- 2024 — 2025
- Type
- Client work
- Status
- production
- 5
- Stages in the funnel
- 3
- Currencies, never summed
- 7
- Top-level modules
- 3
- Frontend engineers
Overview
Vabble turns an unpaid invoice into money now: an exporter posts a receivable, third-party investors fund it, and the exporter gets liquidity without waiting out the payment term. I was on the team that started it and stayed through every reshaping the product went through.
The spine of it is a funnel. An invoice moves Incomplete → In review → Awaiting signatures → To be funded → Funded, three different parties touch it on the way, and every screen in the product is a view onto some state of that journey. Underneath sits compliance: master receivables purchase agreements, per-exporter ledgers, credit assessments — each one required, dated, and carrying an expiry.
The difficulty was never one hard thing — it was volume. An enormous feature surface, an enormous amount of UI, and trade finance logic underneath it that is dense with conditions, currencies and vocabulary specific to the business. Three frontend engineers carried all of it.
That constraint is what forced a real design system. Not a published component library — a shared language of components, patterns and rules that let three people build modals and flows this complex without the product drifting into three different products.
Architecture
The invoice funnel
Scroll to pan
Screens
Modules
The invoice funnel
Five states an invoice moves through, and the product’s real organising principle — the dashboard counts them, the queues sort by them, and most screens exist to move one invoice from one to the next.
- Incomplete — the exporter is still assembling it
- In review — the platform is checking the paper
- Awaiting signatures — the parties have to sign
- To be funded — cleared, waiting on investor money
- Funded — the exporter has liquidity
Three sides to every invoice
An exporter owns the receivable, a buyer owes it, an investor funds it — three counterparties with different rights over the same record, which is why the dashboard counts each one separately instead of reporting users.
Compliance as an interface
Credit score, credit assessment, master receivables purchase agreements, a ledger per exporter, and a slot for whatever else a deal needs — every document required or not, dated, and with an expiry that eventually invalidates it.
Multi-currency by default
Dollars, euros and pounds run through the same funnel and are never added together. Aggregates are per-currency everywhere: the funnel is three stacked ribbons, and funded volume is a chart behind a currency switch rather than a single total.
Scale as the hard problem
Seven top-level modules — dashboard, companies, invoices, transactions, notes, coupons, investors — and a very large amount of UI under each, built and kept coherent by three frontend engineers.
A design system out of necessity
Not an installable package — the internal system of components, patterns and conventions that made a team of three viable on a product this size.
- Multi-step flows carrying a lot of state at once
- Modals dense with information and available actions
- Tables, funnels and charts drawn from shared primitives
- One vocabulary, so three people shipped one product
Back-office ergonomics
Inline edit and copy on every identifier, tabs that keep a counterparty’s information, contact, documents, invoices and transactions one click apart, and states that say what is missing rather than only that something is wrong.
Engineering
Three currencies and no honest total
Dollars, euros and pounds all flow through the same funnel, and there is no exchange rate that makes summing them true — a single figure would be a number the business cannot act on. So every aggregate in the product is per-currency: the funnel is drawn as three stacked ribbons rather than one, funded volume sits behind a currency switch instead of a total, and any component that could quietly add two amounts together had to be built so that it cannot.
Compliance that expires
A counterparty is not compliant or non-compliant — it is compliant today. Agreements and ledgers carry upload dates and expiry dates, so a document set that clears a deal in January blocks one in March with nothing having changed except the calendar. The interface has to show the shape of that set over time, distinguish "never uploaded" from "uploaded and lapsed", and put the missing piece in front of whoever can fix it before an invoice stalls in review.
The vocabulary is the product
Receivable, exporter, buyer, investor, ledger, master receivables purchase agreement, credit assessment — trade finance runs on precise terms, and every one of them ends up as a label, an empty state or a confirmation copy. Getting the wording wrong in a modal is not a copy bug here; it is an operator approving something they thought was something else.
A design system because there were three of us
A feature surface this wide with three frontend engineers on it only has two outcomes: a shared system, or three products wearing the same logo. Building the system cost real time early, against a roadmap that always wanted the next flow, and the return only shows up months later in how fast a new multi-step form arrives and how little of it is new code. That argument is the reason there is a coherent product to screenshot at all.
Stack
- 01React
- 02Next.js
- 03TypeScript
- 04Node.js
- 05Tailwind CSS
- 06Strapi
- 07Vercel
- 08Design systems