The Crop Plan Workbook

Back in 2021 my partner and I had decided to start a farm, and one of the hardest things about the way we wanted to farm was the planning. A market garden grows lots and lots of small plantings in a tiny space. So I went looking for how people actually plan this, and I came across a pretty interesting tool from JM Fortier, probably the best-known market gardener in the world. His process ran on Excel. He kept a pseudo-database of the ways he planted, copied and pasted out of it to build each annual plan, and then laid out the year in what I call paper dolling, little boxes spanning two dimensions, physical space one way and time the other, until every bed was spoken for. Effectively a Gantt chart representing the physical fields throughout the year. It seemed pretty clever to me, a great way to visualize what's happening in a complex plan.

What I didn't like was that he was manually creating those boxes and typing in the data to match what was in his plan. That seemed time consuming and fraught with error. This plan drives the daily decisions on the farm, and the process meant there were two representations of the data. The map everyone looks at could drift grossly out of sync with the daily plans they were working from. And a crop plan is a bad place to be wrong. Every February a market farm bets its year in one sitting: which crops, how many successions of each, which beds they occupy week by week, when every tray gets seeded so it hits the field on time. A hole in the February plan is an empty spot on the August market table, and there's no fixing it by then. That decision had to happen back in winter.

So I had an idea. I had done god-awful amounts of programming in Excel over the years, and I figured there had to be a way to create those rectangles automatically. I pulled out the macro recorder, used it to figure out the right APIs, and lo and behold, it was totally possible. I threw together a demo plan and generated a couple hundred boxes in the blink of an eye.

Then I started seeing ways to improve it. What if the boxes weren't just created automatically, but came out the correct size? In JM's model the columns represent the growing areas and the rows represent time, so if you resize the grid's columns and rows to specific dimensions, you can size every shape off those dimensions and the boxes exactly match the data. Position them off the planting's timing and they slide up and down the page to sit in their row to the exact pixel. It worked so much better than I imagined, so I kept playing. Styling could come from the data too. Different crops got different colors, and a row could carry a border color, a text color, a background color, each one encoding something about the crop. I even worked out a way to use gradients to encode multiple time spans inside a single planting, one color for the stretch before harvest and another for the window it was being harvested.

That would have been an amazing place to stop. It had already bought me a ton of functionality. But I knew I could take it further, because the standing problem with any generated view is what happens when the data changes later. How do you keep the two in sync? If I could somehow link each shape to its row, I could trigger an update when either side changed, and it turns out Excel lets you attach an ID to a shape. Adding that ID to each data-table row gave me the link. Hit the update button and it goes through every planting and mutates its box to match the data in the sheet. It worked incredibly elegantly. The one thing I could never quite figure out was a true two-way sync. In a perfect world I could edit the data or edit the paper-doll view interchangeably. I did manage a push back in the other direction for specific changes, like moving a planting to another growing area, but full two-way binding stayed out of reach. I don't know what it is about elegant hacks into Excel, but I absolutely loved what I accomplished in this project.

None of this was a toy, either. People assume anything built in Excel is instantly inferior to real software, but the Excel data grid is a tool I would still love to replicate in software. It's a shocking amount of functionality to recreate. And that workbook ran our entire farming operation. If it was wrong, the farm was wrong. It had to work. Which made the environment it lived in all the scarier, because I had forgotten how terrible it is to work in VBA. It's a pain to version, it's missing a ton of modern object-oriented programming features, and it's just an absolute mess. Luckily I've always had a knack for manually walking through code and debugging it. Cutting my chops in brutal environments like that is one of the reasons I'm so good at debugging to this day.

The data layer got the same treatment. Fortier's copy-paste process is, to a programmer's eye, an object factory, except every paste breaks the reference to the object. I set mine up like a proper database instead, with real lookups. Every way we plant a crop became a configurable blueprint. A planting is an instance of one, and you override only what differs, this bed instead of that one, a timing shifted a few weeks, while everything consistent about planting that crop stays inherited, the days to maturity, the rows, the spacing. Spring carrots seeded direct in April and fall carrots under row cover are cousins that differ in spacing, days to maturity, and revenue per day the bed is occupied, so they're separate configurations. By the fourth season there were about 340 of them, each carrying more than 150 fields of timing, spacing, tray setups, germination rates, harvest windows, and economics, down to named constants for how many starts I can seed in an hour.

I believe getting good at predictions matters in everything you do. Make strong predictions, then check whether you were right. The workbook made that checking automatic. Every season I compared the plan against what actually happened in the field, and the field was always right. Germination rates got corrected by actual trays. Harvest windows got corrected by actual harvests. Labor estimates got corrected by my own back. By season four the plan scheduled 138 plantings across the farm's 92 beds, and I trusted those numbers because every one had survived contact with a real season, several times over.

Power Query turned the plan into the week's marching orders: what to seed, what to transplant, what to harvest, plus quantity summaries and the report I was most grateful for, the seed order. Seed ordering meant roughly 300 varieties from 18 to 25 companies, but who's counting, reconciled against an inventory of hundreds of part-used packets, and every vendor markets quantities its own way, seed counts here, grams there, "M" for thousands somewhere else. A real pain. The system compressed all of it into one clean order, and it tracked which purchases were organic so the certifier got a paper trail instead of a shoebox of receipts.

We ran the operation on that workbook for four years. Two problems never went away. Excel couldn't give me true two-way binding, and there was no easy way to version the file to protect the data. One wrong drag could silently break a formula, and I had seen that exact thing plague operations back in my mining days, a small accidental break propagating quietly for years. There was no clean way to lay this season's plan beside last year's, and exactly one person on the farm could safely touch the file. So in 2026 I finally replaced it with an actual piece of software, once agentic engineering got good enough to make moving four years of complex logic into an application manageable in a small window of time. That story gets its own page.