Edgewater Farm database and field app

The farm ran on a Microsoft Access database that had accumulated years of real operational history: what was planted where, what came out of it, what was sold. All of it was reachable only by opening a database file on one office computer, through forms designed for a keyboard and mouse.

The crew with the most direct knowledge of operations had the least ability to record it. Data entry happened later, from written notes, by someone else, which introduced errors.

Two parts. First, the migration: a normalized MySQL schema that preserves the meaning of the Access database rather than only the contents of its tables, since the legacy schema encoded operational rules in places a row-by-row copy would drop.

Second, a progressive web app over that schema, built with FastAPI and SQLAlchemy on the server and HTMX with Tailwind on the front end. HTMX was chosen because the required interactions are form submissions and partial page updates, which do not justify a JavaScript framework and its build pipeline.

Two audiences, two different interfaces

The application has two distinct user groups, and separate interfaces for each.

• Capture flows for the crew are simple and mobile-first. Planting, harvesting, and selling are three separate paths, each designed to be completed on a phone, outdoors, in as few taps as possible. Any field that can be inferred is inferred.
• Admin flows are dense and desktop-oriented. The office needs to see many records at once, correct mistakes, and run queries, which a phone-optimized layout would have made harder.

The two share a database and little else.

In active development, with a test suite covering the data layer and the capture flows, working toward cutover from the Access database. The repository is private, since it is a real business's operational data.

Back to all work