CASE 10 / Product & systems
From a day's work to a traceable payment.
A solo-built farm operations app: attendance, wage calculations, and worker ledgers, with access scoped to each farm.
- THE PROJECT
- Agrithm
- THE CONTEXT
- Independent product
- THE CHAPTER
- Web app / PWA
- THE PROBLEM
- A friend's father managed farm records on paper, separating work done from money owed.
- WHAT I OWNED
- Solo product design, interface, API, farm-scoped permissions, wage engine, and worker ledger.
- THE RESULT
- Connected attendance and work records to wage calculations, payments, receipts, and ledger history.
From the live product
Owner-supplied Agrithm workspace screenshot, shared 28 October 2026. DEMO - Riverside Plot uses demo data, not a customer's farm records.
My contribution: Solo implementation of the farm-scoped dashboard and connected attendance, work, wage, and payment workflows.
COMPONENTS / RESPONSIBILITIES / SCOPE
How the parts fit together.
The application has a Next.js frontend and a Fastify API backed by MongoDB. This map describes responsibilities in the current implementation, not farm or customer infrastructure.
01
Field interface
A Next.js and React PWA organizes attendance, work, finance, and reports around the selected farm.
- The boundary
- The interface exposes permitted actions, but the API decides whether the user may perform them.
- Implementation note
- Nine-language layouts and phone navigation share the same application rather than separate native apps.
02
Farm-scoped API
Fastify resolves the authenticated user's active farm membership and checks the requested action.
- The boundary
- A role in one farm does not grant access to another. The caller does not choose the role used for authorization.
- Implementation note
- One modular API keeps deployment small while separating workforce, wages, finance, and reporting responsibilities.
03
Wage engine
A shared server-side engine calculates daily, hourly, task, and fixed-period wages with explicit components.
- The boundary
- Money is represented in integer minor units, with bounded inputs and deterministic rounding.
- Implementation note
- Saved calculations retain their input snapshots rather than silently changing when a wage rule is edited later.
04
Worker ledger
MongoDB stores source-linked financial effects, payments, receipts, and reversals.
- The boundary
- A unique source-effect key prevents a repeated posting from creating another ledger entry; conflicting values are rejected.
- Implementation note
- Corrections add reversing entries instead of erasing the original financial history.
Conceptual responsibility map. Not a production deployment diagram or a screenshot.
01 / The problem.
A friend's father was managing farm records on paper. Attendance, work completed, wages, advances, and payments were parts of the same problem, not separate forms. I built Agrithm to connect those steps while keeping each farm's workers, permissions, and finances separate.
02 / My role.
I built Agrithm end to end as an independent product: the Next.js interface, Fastify API, MongoDB data model, farm-scoped permissions, wage engine, financial workflows, and PWA behavior. I also implemented the nine-language interface, reports, and regression coverage.
- My contribution
- Solo product design and implementation across the interface, API, authorization, calculations, and worker ledger.
- Shared scope
- Built with Next.js, Fastify, and MongoDB, hosted on Vercel, Render, and MongoDB Atlas.
- What changed
- A connected farm workflow from attendance and work records to wage calculations, payments, receipts, and a source-linked ledger.
03 / Follow the work, not just the balance.
The workflow starts with the selected farm and its workers. Attendance and completed work provide inputs for wage calculation. Overtime, bonuses, signed adjustments, advances, and payments remain separate components, so the resulting amount can be explained.
I built payment periods and receipts around that flow. A receipt records gross pay, advances, previous dues, the amount paid, and the remaining amount. The application records payment activity; it is not a claim that Agrithm moves money through a bank.
04 / A role needs a farm.
The API checks identity, active membership in the requested farm, and the permission needed for the action. A Supervisor can manage attendance without gaining an Accountant's payment permissions. Hiding a button in the frontend is not the authorization boundary.
I expose the allowed actions to the interface so people see a relevant workspace, while retaining the same server-side checks for requests made outside the UI. The linked engineering note follows this decision in more detail.
05 / Make the arithmetic and retries explainable.
I centralized wage calculation rather than repeating formulas across screens. Rates and amounts use integer minor units; fractional quantities have explicit numerators and denominators. The engine uses integer arithmetic and deterministic rounding, including half-day, hourly, and task-based calculations.
Each ledger effect points back to its source. Repeating an identical source effect returns the existing entry; a retry with conflicting financial values is rejected. A correction creates an opposite entry linked to the original instead of overwriting history. That makes both the current balance and the reason it changed inspectable.
06 / Offline means read-only, not secretly queued.
The PWA can show supported data downloaded during an earlier online visit, scoped to the signed-in user and marked with its freshness. Writes remain online-only. I chose an explicit limitation over a queued payment or attendance change that could look saved before the server accepted it.
Downloaded financial data still belongs to the browser profile. Logout, session rejection, account changes, and the clear-offline-data action remove private caches. The shared-device warning matters: offline access is not a promise of continuously refreshed permissions.
07 / Check the rules behind the screens.
The regression cases cover wage types, half-up rounding, signed adjustments, and overpayment. Model tests check integer-money validation and the unique ledger source-effect index. Permission and route tests exercise the distinction between farm membership and action access.
Browser coverage checks desktop and mobile workflows, translated layouts, and offline behavior. Synthetic demo workers and balances make those paths inspectable without publishing anyone's employment or financial records.
08 / The result.
- Connected attendance and completed work to wage calculations, worker payments, receipts, and ledger history.
- Kept permissions tied to farm membership rather than a global role.
- Implemented auditable financial effects and explicit read-only offline behavior.
- Built a responsive nine-language interface over the same API and domain rules.