Bringing the Power of Big Data to a Local Farm

How I built a mobile crop quality logger for One Acre Farm, connecting planting records, field observations, and sales data to make farm data easier to use for real decisions.

iOS-style crop sprout icon for the One Acre Farm crop logger post — A field-first tool for turning planting records into structured crop and quality data.

One Acre Farm already had years of valuable data. Planting spreadsheets tracked crop names, varieties, beds, fields, dates, quantities, and notes. Sales records showed what actually moved. The problem was that none of it was easy to use together.

“I collected data for years but then there was no use for it, so I just stopped.”— Farmer Mike

That became the core of the project: not just collecting more data, but making the data useful. I built a mobile-friendly crop quality logger that fits into the farm’s existing workflow instead of replacing it.

The app keeps the existing Google Sheets workflow in place, then syncs planting records into a structured Convex database where crops can be searched, reviewed, and logged in the field.

What changed

Before, farm data existed mostly as passive records. After the logger, the same information became easier to act on. Staff can see what was planted, where it was planted, how crop quality changes over time, and whether certain crops are being overplanted or underused.

Connect Google, choose a planting spreadsheet, and sync sheets.
Review crops by field, bed, crop, variety, date, and notes.
Log quality with consistent dropdown answers instead of loose field notes.
Prepare crop quality data for analysis alongside sales and planting records.

sync flow

Google Sheets -> row parser -> Convex crop records -> mobile quality logs -> Databricks analysis

The hard part

Real farm data is messy. A single bed can contain multiple crops. Replants can be written in plain English. Locations can be described through field names, greenhouse notes, high tunnel references, or other shorthand that makes sense to the farm but not to a database.

The parser had to respect that messiness. Instead of forcing the farm to rewrite its workflow, the app interprets the existing sheets and turns them into structured crop records.

Why Databricks mattered

The app solves the data entry problem. Databricks helps solve the analysis problem. Once crop quality logs, planting records, and sales data are in a usable format, the farm can start looking for patterns: which crops performed well, where quality dropped, what was overplanted, and how future planting decisions could better match actual demand.

The larger goal is decision support. Not dashboards for the sake of dashboards, but a system that helps the farm understand what happened and plan better next season.

Why it mattered

This project was not about bringing enterprise software to a small farm for no reason. It was about taking data the farm already cared enough to collect and finally giving it a purpose.

The stack — Next.js, TypeScript, Tailwind CSS, Clerk, Convex, Google Sheets, and Databricks — mattered because it supported the workflow. The real win was making data collection feel useful again.