Small Change
A UPI-first money app for freelancers and studios
Small Change is a sample brief. We imagined a new money app for India's freelancers and small studios, with a licence and a plan but no look yet, and built its identity and product together. The company is imaginary. The app isn't: we designed and engineered it, and you can send, budget and invest in the live build below.
A sample brief, a real product. We wrote this brief ourselves. The business is imaginary; the product is not: we designed and engineered it, and you can use it above. We publish results only for work a client has let us verify, so this page shows none.
The brief
We imagined a money app for freelancers and two-person studios: people who get paid by UPI, pay rent by IMPS, run a SIP and never quite know what's theirs to spend. The company had a licence and a plan but nothing that looked like it, so we built the identity and the product surface together.
The problem
Money is trust. An app like this has to feel established on day one without pretending to a history it doesn't have, and it has to behave correctly when the network drops halfway through a payment.
- An identity that reads as safe and modern
- One system from app icon to statement
- Payments that never send twice
- Balances you can check against every posting
The approach
The same people designed the identity and the interface, in the same weeks, so nothing was lost in a handoff. Underneath, every rupee is a posting in a double-entry ledger, and every send carries an idempotency key, so a double tap or a retry on a bad connection moves money once.
What would change for a business like this: the brand and the product say the same thing, and the team can add screens without breaking either.
- A tight type and colour system, documented
- One component library for brand and product
- Copy and motion drafted together
- A ledger-first data model from the first commit
What shipped
- Balance derived from postings, never stored
- Idempotent send: tap twice, the money moves once
- Payees by UPI ID, IMPS or NEFT
- Accounts and pots
- Physical and virtual cards with limits, controls and freeze
- Budgets, scheduled payments and insights
- Investments and monthly SIPs
- CSV statement
- Support tickets and disputes
Under the surface
How it is built
A NestJS core models money double-entry on PostgreSQL behind a Next.js front end. In production, payments run over UPI, IMPS and NEFT through a partner bank, Account Aggregator consent brings in balances from other banks, Razorpay handles top-ups, and every money movement is an idempotent, audited command.
- Double-entry ledger: balances derived, never stored
- Idempotency keys on every mutation endpoint
- Bank and Razorpay webhooks verified and replay-protected
- Terraform-managed AWS in Mumbai with least-privilege IAM
Considered and turned down
Firebase would have been quicker to start; a relational ledger and typed migrations mattered more for money.
Stack
The mechanism, working
The part of Small Change that was hardest to get right, as a small model you can operate.
Double-entry ledger
Balances are derived from postings, never stored. Money can’t be created or lost, only moved.
Idempotent money movement
Every mutation carries a key. Retry the same request a hundred times, the transfer happens once.
