Project
JBP — Cost control for produce sourcing
Client case — Agrícola Industrial JBP (northwestern Mexico): their produce-sourcing operation now knows the real margin of every trip and where money was leaking. Custom system for Agrícola Industrial JBP, an agro-industrial sourcing company in northwestern Mexico that buys tomato and chili and delivers it to industrial plants. It costs every truckload against the purchase order, separates estimated margin from real margin, and explains the gap by its two causes — weight shrinkage and quality penalty — money that used to leak without anyone measuring it. Built and shipped solo; in production.
Custom software designed, built and deployed solo under contract for Agrícola Industrial JBP SPR de RI, and operated by the client. Published with their permission. The repository and all business data are private; the description covers architecture and engineering decisions only.
Stack
Impact
- Made margin leakage visible: the system splits estimated vs real margin per trip and attributes the difference to shrinkage or quality penalty, which is the number the business now negotiates on.
- Lets the business compare its two sourcing routes — buying through a supplier versus buying direct from the grower and paying harvest and freight separately — instead of guessing which one pays better.
- Replaced spreadsheet-based control of supplier current accounts, advances and bank reconciliation across two legal entities and two bank accounts.
- Field capture works with no signal: crews record loads next to the scale and the data syncs when coverage returns.
- Shipped to production with automated deploys, so fixes reach the client the same day they are merged.
What I did
- Money is stored in integer cents and weights in grams — never floats, because the whole business is a subtraction of cents per kilo.
- Every operation that touches money goes through idempotent callable Cloud Functions; direct client writes are a deliberate exception limited to offline field capture, guarded by strict Firestore rules.
- Role-based access via custom claims (admin, partner, office, supplier, read-only), with token revocation when a role changes.
- Suppliers cannot see sale prices, purchase orders or freight rates — they read a trigger-maintained projection of their own trips, enforced by a Firestore rule with its own test, so the company's per-kilo margin is never exposed.
- Dashboard totals come from trigger-maintained monthly aggregate documents that recompute the full month rather than incrementing, because Firestore can deliver the same event twice and a repeated increment inflates a total silently.
- Business dates are pinned to America/Mazatlan, not UTC — with the wrong zone, anything captured after 23:00 fell into the next day.
- Nothing is deleted: soft-delete plus an author audit trail on every movement of money.
- Four-level test pyramid on isolated emulator instances — unit tests, 123 Firestore/Storage rules cases and 93 Cloud Functions tests — so a live demo can keep running while the suite executes.
- Modules delivered: trips and costing, money and advances, activities per crop cycle, collections, plant reconciliation, banking, finance reports and catalogs.
Architecture
- Monorepo: apps/web (Angular PWA) + functions (Cloud Functions v2, TypeScript on Node 22)
- Shared calculation core synced into functions so client and server cost a trip with the exact same code
- Firestore multi-entity model: catalogs shared across both legal entities, movements always scoped by entityId
- Offline-first capture through the Firestore SDK's local persistence; money operations through callables
- Trigger-maintained aggregates for dashboards; scheduled rebuild scripts for historical recalculation
- Two isolated emulator instances (development and tests) on separate port ranges, so the test suite never disturbs a running demo
- CI/CD with GitHub Actions: pull requests verify, pushes to main verify and deploy