Fruit Tree Inventory: Spreadsheet or App?

Most orchard records start in a spreadsheet, and for the first season that is often the right call. It is free, flexible, and you already know how to use it. The trouble arrives around year two or three: a photo folder nobody can match to a row, a dead tree replaced by a seedling with no record of what stood there before, and a crew member who typed a cultivar three different ways. This article covers what a tree inventory must contain, the exact point where a spreadsheet stops holding up, and an honest checklist for deciding whether a dedicated app is worth paying for.

The fields a tree inventory actually needs

A tree register is not a garden journal. It is an identity system: every row is one physical tree, and every other record (sprays, harvests, photos, diagnoses) points back to that identity. Whatever tool you use, these fields are the non-negotiables.

• Tree ID: short, permanent, never reused. A running number (001, 002) or a block-and-position code (B2-07). If the tree dies, retire the ID; the replacement gets a new one.
• Species and cultivar: spelled one way only. Decide on Nam Doc Mai or NDM on day one and never mix both.
• Rootstock, if you know it: it sets tree size, spacing tolerance, and in some crops replant tolerance. Record Unknown honestly if you do not know.
• Planted date: the denominator for every years-to-first-fruit and yield-per-age comparison you will ever make.
• Location: GPS coordinates or a row-and-position code, ideally both. Text like third mango past the gate is not a location.
• Status: alive, removed, replaced, with the date of the change.
• Event notes: pruned, treated, grafted, diagnosed, with dates. Free text is fine here.
• Yield or count history: even a rough buckets-per-tree estimate each season turns the register into a laggard detector.

A stable ID is the whole game. Every other field can be corrected later; a tree whose identity drifts between rows has no history at all.

A worked example: where the spreadsheet breaks

Take a 48-tree mango block, tracked in one sheet: ID, cultivar, planted, notes. In year one it works. In year three, four things happen in the same month. First, you photograph a suspicious trunk and save the picture as 20260612_trunk.jpg in the camera roll; the sheet cannot hold photos, so the link lives only in your memory. Second, a helper adds a tree at the bottom while you add one in the middle, and now two offline copies disagree. Third, tree 23 dies and you replace it; if you overwrite the row you lose four years of cropping history for that position, and if you add a row you must remember which row is current. Fourth, you group by cultivar and get Nam Doc Mai, Namdokmai, and Nam Doc Mai (grafted) as three separate groups.

None of these is a storage problem. The sheet stored every character fine. They are identity, concurrency, and history problems, and they are structural: a flat table with no enforced IDs, no photo attachment, and no edit log cannot solve them no matter how carefully you arrange the columns.

What an app actually adds

A good tree-tracking app adds exactly four things a spreadsheet lacks: an enforced schema (the ID, photos, and dates are fields, not conventions), GPS-backed location (each tree is a point on a map, so a new hire can find B2-07 without asking), multi-device sync (two people can update without forking the file), and a per-tree timeline (every photo, count, and note attached to one tree and ordered by date). That last one is the quiet superpower: the question how did this tree do compared with its neighbours becomes a lookup instead of an archaeology project.

What an app does not fix: bad data. If nobody records the spray, no schema helps. And be careful about fit, because a lot of farm management software is built around row crops: it thinks in fields and beds, not in individual trees that live for decades. A tree-level data model (one record per tree, spanning years, with its own photo history) is the feature that separates orchard tools from generic farm record apps. It is also the feature worth checking first in any demo.

Spreadsheet, generic farm app, or tree-level app

• Spreadsheet: right for under roughly 20 trees, one person, no photos, no crew. Cost: zero. Failure mode: identity drift as soon as a second copy or a second person appears.
• Generic farm app: right when you need spray and harvest compliance records across a mixed farm and trees can be represented as blocks rather than individuals. Failure mode: tree-level questions (this specific tree flowered early three years running) are unanswerable.
• Tree-level app: right from about 20 trees up, or at any size once you want photos, GPS, and year-over-year per-tree history. Cost: a monthly subscription, so weigh it against the hours you spend reconciling the sheet. Failure mode: an empty app. It only works if the first inventory actually gets entered.

The 10-point checklist before you switch

1. 1Does every tree get a permanent ID that survives removal and replacement?
2. 2Can you attach photos to a specific tree and see them as a timeline?
3. 3Does the app put trees on a map with GPS, and can you find a tree from the map?
4. 4Can two people edit without creating conflicting copies?
5. 5Is the data model tree-by-tree, or field-by-field with trees as an afterthought?
6. 6Can you import your existing spreadsheet (CSV) so starting does not mean retyping?
7. 7Can you export everything back out (CSV)? You own your data; verify it before you pay.
8. 8Does it work on the phone you carry in the field, not just on a laptop?
9. 9Is there a free trial long enough to enter a real block, not three demo trees?
10. 10What happens at your scale in five years: check the tree-count limits and the price jump between tiers.

Migrating without losing a season

If you already have a sheet, do not start over. Export it as CSV with one row per tree, make sure the ID column matches what you will print on tags, add status for trees you know have died, and import that. Then, on the next walk of the rows, photograph every tree once: those geotagged photos become the photo history and, with a GPS-clustering pipeline, they place each tree on the map automatically. The spreadsheet becomes an archive rather than the live system, and the live system starts accurate.

This is the workflow CanopyTwin is built around: a tree-by-tree inventory on a live satellite map, QR tags and printable tag sheets for every tree, photo history per tree, and CSV import so your spreadsheet moves in instead of being abandoned. The Grower plan covers up to 50 trees and CSV export is listed from the Orchard plan up, every plan starts with a 30-day free trial, and there is a live demo orchard at canopytwin.com/map you can walk through before you enter a single tree of your own.