Fintech
Prune is a banking-as-a-service platform that lets businesses issue and operate multi-currency accounts (EUR, GBP, USD) with full IBAN, Sort Code, and ACH details. I built the frontend across two surfaces: the business dashboard — accounts, transactions, payouts, beneficiaries, debit requests, and role-based team management — and the internal admin console for business onboarding (KYB), eligibility, pricing plans, and account approvals.
Context
Businesses that want to offer banking features rarely want to become a bank. Prune provides the account-issuing, payout, and transaction rails as a service, so a business can spin up multi-currency accounts and move money under their own brand. That demands two very different surfaces — a self-serve operator dashboard for the business, and an internal admin console for Prune to vet and manage those businesses.
Constraints
Role & Team
Process
01
The platform serves two fundamentally different users — businesses operating their own accounts, and Prune staff vetting those businesses. I separated them into distinct Next.js route groups, each with its own layout, navigation, and permission model, so operator and staff flows never leak into each other.
02
Money movement needs guardrails. I built RBAC around an initiator/approver pattern: a useHasPermission hook gates every sensitive action — transaction initiation, approvals — so the same UI adapts to each team member's role rather than hiding logic behind a single admin flag.
03
Each account carries its own real banking identifiers — IBAN, Sort Code, ACH Routing — across EUR, GBP, and USD, with per-currency transaction views, payouts, and downloadable statements. Receipts and statements are generated client-side as PDF and exported to Excel, matching exactly what's on screen.
Outcome
Businesses onboarded
Account requests approved
Active accounts issued
Lessons
Building money-movement software taught me that permissions aren't a feature you bolt on — they're the architecture. Once you model an initiator/approver flow honestly, every screen has to answer 'who is allowed to do this, and what happens when they can't?'. Splitting the operator and admin surfaces early kept that complexity contained instead of letting two very different products fight inside one layout.
