Rogers Manokan — Poultry Distribution System
A commissioned reconciliation system for a growing poultry distributor — built so the books can be trusted, audited, and never quietly rewritten.
Client
Rogers Manokan, Aklan
Year
2026
Role
Sole Developer
Why It Exists
Rogers Manokan is a poultry middleman in Aklan. They buy chicken by the kilo and move it — to wet-market stalls, carinderias, restaurants, and walk-in customers across the province — through a small fleet of delivery agents who go out each morning and come back each afternoon with cash, credit slips, and whatever didn't sell. For years the whole operation ran on spreadsheets and memory. That works when you're small. It stops working the moment you grow. By the time they came to me, the business had outgrown its own bookkeeping. Inventory was tracked in kilos but reconciled by feel. Nobody could say with confidence whether a bad day was a slow market, spoilage, a miscount, or an agent skimming. Cash and credit blurred together. Collections against old credit sales got lost. The owner knew the business was making money but couldn't prove how much, or trust the daily picture enough to make decisions on it. They commissioned me to replace the guesswork with something that could be trusted — a system where the numbers were accurate, instant, and impossible to quietly alter after the fact.
What I Built
I built a desktop-first inventory and sales system on Next.js with a Supabase PostgreSQL backend. The UI is deliberately unglamorous — numbers-first, spreadsheet-inspired, built for minimal clicks during a busy morning, because the people using it think in rows and totals, not in dashboards. Two decisions defined the architecture. First, immutability: transaction history is never overwritten and inventory movements are never deleted. Prices and acquisition costs are stored date-effectively, so a report from three months ago reflects the margins that were true then, not today's. Second, the daily closure system — the part I'm proudest of. At end of day the owner closes the books, which snapshots that day's totals into a sealed record and locks it. Reopening a closed day is possible, but only with a mandatory reason that gets written to an immutable audit log, and the reopen count is tracked and flagged. I enforced the lock at the database level with PostgreSQL triggers, not just in the UI — because hiding an edit button is not the same as preventing an edit. Sales are recorded per delivery and deduct inventory automatically; physical counts are reconciled against the system's expected ending stock, and the variance is surfaced, never hidden.
The Hardest Part
The hard part wasn't recording sales — it was making the books trustworthy enough that the owner would actually rely on them, while still flexible enough to survive real life. Real distribution is messy: spoilage, miscounts, deliveries reported late, plain human error. A system that's too rigid gets abandoned because people can't enter what really happened; a system that's too loose lets numbers be quietly rewritten until they mean nothing. I resolved that tension with a clear rule — the system warns, but rarely blocks; and nothing the system records can disappear without a trace. Negative inventory throws a soft warning but still lets you encode it, because sometimes a late delivery report genuinely arrives out of order. Corrections happen through logged adjustments with a mandatory reason, not by overwriting the original. The most satisfying piece was the variance trend — once daily closures accumulate, you can plot variance over time and see shrinkage patterns emerge. A single bad count is noise; the same negative variance every Tuesday on the same route is a signal. Designing for that turned the system from a ledger into something that could actually answer 'where are we losing chicken?'
What I'd Do Differently
I'd build a mobile companion for the delivery agents from the start. Right now sales get encoded back at base, which means there's a gap between what happens on the route and what enters the system — and that gap is exactly where errors and disputes live. If agents could record each delivery on a phone in the field, ideally offline with a sync queue, the data would be tighter at the source and reconciliation would have far less to argue with. The reconciliation engine I built would get dramatically more powerful the closer its inputs sit to the moment of sale.
The Impact
The system is deployed and reconciling real operations daily. Rogers Manokan went from end-of-day spreadsheet math to instant, accurate sales and inventory totals, with a daily reconciliation they can seal and trust. For the first time the owner can see variance as it happens instead of discovering shortfalls weeks later — and because every adjustment and reopen is logged, the books can be audited rather than taken on faith. This was my first commissioned build for a real, growing business that was paying me to solve a problem they felt every single day. Watching an owner stop guessing about their own money — and start making decisions from numbers they trusted — is what made me realise the point of this work was never the code. It was the trust the code earned.
“The point of this work was never the code. It was the trust the code earned.”
Skills Demonstrated
- Audit-safe financial data architecture with immutable transaction history
- Database-level integrity enforcement using PostgreSQL triggers and RLS
- Daily reconciliation and sealed-closure workflow with full reopen audit trail
- Variance trend analysis for shrinkage and loss detection
- Numbers-first operational UX designed for fast, low-friction daily entry
Tools & Technologies