AL Lending
A lending book that had outgrown Google Sheets, rebuilt as a transactional loan management system for the staff who use it every day.
Built in-house for my own lending operation
165
Tests on the money engines
33
Data models
4
Loan products, each with its own engine
33
Screens, staff and owner roles
What it needed to do
AL Lending runs salary-based lending — money advanced against a borrower's payday and collected on each cutoff. The entire operation lived in Google Sheets: the client book, four different loan products, every amortization schedule, the cash positions across bank channels and the vault, and the payday run itself. That worked until the client list grew. Then the sheets got slow, the automation lagged behind the volume, and staff spent their day waiting on recalculation instead of collecting. Worse, the book keyed identity to a row's position rather than to the client — so a sort could quietly point a payment at the wrong person.
What I built
A full replacement, designed around one goal: fewer keystrokes for the people entering data all day. Four loan products are modelled explicitly rather than approximated — fixed-term flat-rate installments, declining-balance loans that accept top-ups mid-term, revolving loans where interest and capital are settled independently, and item-backed loans. Each has its own calculation engine, and each engine is a pure function under unit test. Every money-changing action — release, payment, top-up, interest settlement — runs inside a single database transaction that also writes its audit-log entry and its ledger entry. All three land or none do, so the ledger cannot drift from the loan book, and every entity keys on a permanent UUID so nothing derives identity from row order again. The keystroke work is where staff actually feel it: any peso field accepts a formula, so typing =1000+20*3 previews ₱1,060.00 as you go; filters apply as you type and live in the URL, so there is no Apply button anywhere in the app and any filtered view is shareable; a quick-quote tool answers what a loan would cost before a client record exists, then carries its inputs into the real loan form so nothing is typed twice; and payday forms arrive pre-filled from the day's log, leaving only the figures that exist solely on the physical terminal report.
Stack used
- Next.js 15
- React 19
- TypeScript
- Prisma
- PostgreSQL
- Supabase Auth
- Zod
- Vitest
- Vercel
- Service tier
- Custom Build
- Industry
- Salary lending · Internal operations
- Year
- 2026
Next case study
Strike & Restore
A booking system for a resort spa's own team — massage and boxing sessions on a weekly grid, with double-booking made impossible at the database rather than in the interface.
Ready to build something that earns its keep?
Tell us about the project. You'll get a straight answer on scope, timeline, and price — usually within one business day, and always before you're asked for anything.
Prefer email? siteandriseweb@gmail.com