WORK / MYLEDGER
MyLedger
A wholesale ledger replacing the paper notebook — stock tracking, per-buyer rates, due tracking, and instant invoices, live with a real distributor.
ROLE
Product design & engineering, built with Claude Code as an engineering partner
STACK
Flutter · Firestore · AWS · Claude Code
TIMELINE
Live 3+ months
STATUS
Live — Gate of India Food
THE PROBLEM
Every wholesale business I looked at runs on a paper notebook — stock, dues, and per-buyer pricing tracked by hand. That doesn't scale past a certain size, and it's opaque: the owner can't see profit in real time, and staff mistakes are invisible until a reconciliation goes wrong.
MyLedger replaces the notebook: stock tracking with real average cost, per-buyer custom rates, automatic due tracking, instant PDF invoices, staff accounts with activity logs, and profit reporting.
CONSTRAINTS
- —Real, non-technical end user — every screen has to be usable without training
- —Multi-staff access on one shared business account, so permissions and activity logs matter
- —Needed to launch fast enough to test with a real distributor, not a demo
- —Data model has to support per-buyer custom rates without turning pricing into spreadsheet chaos
ARCHITECTURE
Flutter client talking directly to Firestore, with security rules doing the access control work a backend service would otherwise handle. AWS for document and PDF storage, subscription logic gating premium features.
- 01Flutter — single codebase for the app the owner and staff both use
- 02Firestore — primary data store, average-cost stock valuation computed on write
- 03Security rules — enforce per-staff, per-business data isolation directly in Firestore
- 04AWS — invoice PDFs and document storage
- 05Subscription layer — gates features by plan without a separate billing service
DECISIONS
1. Average cost over FIFO
Real wholesale stock doesn't arrive in clean batches — a true FIFO model needs lot tracking most buyers don't do by hand either. A running average cost is close enough to reality and dramatically simpler to compute and explain to a non-technical owner.
2. Firestore security rules over a custom backend
A dedicated backend would have meant more infrastructure to run and patch for a single-tenant-per-business app. Firestore's rules engine can express "staff can only touch their business's data" directly, which cut out an entire service.
3. Built with Claude Code as an engineering partner
I specified the data model, security rules, and UX; Claude Code handled a large share of implementation. The judgment call was knowing what to specify precisely — schema, access rules, pricing logic — and what to delegate. Not outsourcing the thinking, just the typing.
RESULTS
2,000+
Bills processed
3+ mo
Live with a real distributor
1
Business fully migrated off paper
WHAT I'D DO DIFFERENTLY
I'd build the activity log from day one instead of adding it after the first "who changed this price" question from the owner. Multi-staff systems need an audit trail before they need almost anything else.