A farm’s records, connected.

Farm records were kept for the office, not the field. The job was to find out how production data actually got captured, then build something that survived the conditions on the farm.

Three record types came out of that: who was present, what was produced, and who worked there. That is the whole scope of the MVP.

I built the three-module MVP in a six-week Ashesi Innovation Lab engagement, with the farm-operations side.

• Offline-first field work — records are entered where connectivity is poor, not only at the office.
• Authentication and authorization — custom auth and role-based access on FastAPI and PostgreSQL, so a farmhand and a manager don’t see the same records.
• A public face for the farm — a website for the business. Its address isn’t in the record, so it is described, not linked.

The code isn’t public, so no schema or endpoint is described here. It would be a guess.

Follow the records, not a feature list

The engagement produced three record types, so the MVP is organised around them, not around a generic suite of farm features.

Build for the connection the farm has

Offline-first was the shape of the product, not a later optimisation. Records are captured in the field and reconciled after, so a dropped connection doesn’t stop the day’s work.

Decide access in the service

Custom auth and role-based authorization live on the backend, next to the records they protect, not in the interface.

A working MVP is recorded in the résumé and the Innovation Lab brief: three modules, custom authentication and role-based access, and a public site for the farm.

Delivered

Three modules, working. Attendance, produce and employees.

Deployment

None evidenced. No production deployment or rollout in the record.

• Profile and experience recordThis siteThe Jul–Sep 2026 Innovation Lab role around it.
• Résumé (PDF)PDFThe supplied résumé record this account is drawn from.
• Innovation Lab briefNot publicThe written project scope. No public link exists.