How I Built My Own ERP for the Garden: A Gardener's Guide to Digital Tools

The Dream of a Digital Garden

For years, I've kept a mental map of my garden—where the tomatoes go, when the beans need trellising, how much compost each bed gets. But every time I tried to turn that map into a spreadsheet or a scheduling app, it fell apart. I'd sketch out a plan, then stare at a blank form and give up. The vision was clear; the execution was not.

Then AI tools came along, and I finally built the system I'd always wanted. Now my garden runs on a custom ERP—purchasing seeds, tracking planting, and logging harvests all flow into one database. It even generates a balance sheet of sorts: what I've spent, what I've grown, what's still in the ground. It's in beta, but it works.

Getting here wasn't a straight line. I hit four major snags, each one enough to make me want to scrap the whole project. Here's what I learned, so your own digital garden doesn't get choked by weeds.

Start with the Soil, Not the Sprinklers

My first mistake was obsessing over the interface. I spent days arranging buttons and dropdowns, convinced that a pretty screen was the real work. It wasn't. The heart of any garden system—or any ERP—is how an action becomes a record. When I plant a seed, that's one kind of event. When I harvest, that's another. When I buy soil, that's a third. Each needs to translate into a consistent ledger entry.

Early on, I let each module handle its own bookkeeping. The planting module tallied its own numbers; the harvest module did its own math. It was a mess. The totals never matched, and I couldn't tell which one was right. So I rebuilt the core: every module now just emits an event, and a central engine translates that event into ledger lines. One rule set for all transactions. Now, when I log a harvest, the system automatically updates my inventory and my yield report. No more arguments between modules about who owes what.

The lesson? Don't scatter your logic. Keep the translation rules in one place, configurable, so you can add new crops or activities without rewriting everything.

One AI Model Beats a Committee

For the actual coding, I relied on AI. But I made the mistake of using different models for different parts. I thought I was being clever—let the strongest model handle the trickiest logic, another for the simpler stuff. Instead, I got a Frankenstein codebase. One model's code used a different style from another's. Naming conventions clashed. Error handling was inconsistent. Fixing one thing broke something else.

Worse, when I asked a different model to modify code written by another, it would rewrite it from scratch, losing the original context. The result was a patchwork that looked fine on its own but fell apart when connected.

I settled on a single model for the whole project. Consistency made debugging manageable. I could predict how it would handle a problem because it always approached things the same way. If you're building your own garden tool, pick one AI assistant and stick with it. A single, reliable tool is better than a trio of brilliant ones that can't agree.

Version Control: Your Garden's Fence

I didn't use version control at first. I saved files with names like "final_v2_reallyfinal.xlsx" and kept them in folders. Then one big refactor broke the whole system, and I couldn't roll back because there was no clean backup. I had to rewrite days of work—and worse, I lost the confidence that I could finish.

Now I use Git religiously. Every stable milestone goes to the main branch; experimental changes live in separate branches. If something breaks, I can switch back in minutes. For a solo project, version control is your safety net. Without it, you're gardening on a cliff—one wrong move and everything tumbles.

The Hidden Trap of Conversational Interfaces

Once the system was running, I wanted to talk to it. I turned my garden modules into MCP servers—think of them as API endpoints that respond to natural language. I could say, "How much compost do I have left?" and get an answer without opening a dashboard. That part worked beautifully.

But here's the trap: some calculations lived in the frontend. The dashboard would compute totals correctly because it ran the math in the browser. The conversational interface, though, only passed parameters and displayed results—it never executed that frontend logic. So the numbers were wrong. I'd see one total on the screen and a different one when I asked via chat. It took me a while to realize the frontend was doing the arithmetic.

The fix was to move all calculations into the backend, no matter how trivial. Now the frontend and the chat both just display what the server computes. I also added a double-check: the backend calculates every figure two ways and compares them. If they don't match, it stops the record from being saved. That's my double-entry bookkeeping for the garden.

What AI Didn't Change

AI gave me the ability to write code without being a programmer, but it didn't give me the ability to think clearly about what I wanted. That part was still on me. I had to decide what a "planting" event meant, how to categorize expenses, what reports mattered. The AI was a tireless assistant, but it couldn't make judgment calls.

So my advice to any gardener who wants to digitize their plot: start with a clear picture of how your garden works. What actions do you take? What data do you want to track? AI can build the tool, but you have to know what it should do.

It's Alive

My garden ERP is still in beta. It's not perfect—some modules need polishing, and the chat sometimes misunderstands me. But it does one thing that makes it all worthwhile: it generates a balance sheet of my garden's health, automatically, from the records I log. I can see at a glance what I've invested, what's thriving, and what's ready to harvest.

That's the dream, finally realized. It didn't come easy, but it came. If you're thinking about building your own system—for your garden or anything else—know that the pitfalls are real, but so is the reward.