Commercial Beekeeping Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does modelling hives instead of pallets happen so often?

Because every product in the category starts from the hive, and for good reason. Hive record apps grew out of the hobbyist and sideliner world where a colony has a name, an inspection history and a queen you can point at. HiveTracks handles that properly and Nectar is serious about structured field capture at scale. Neither was designed to be an inventory system.

Your crews do not handle hives. They handle pallets. A forklift moves four at a time, a semi carries a known number of pallets, a drop is a pallet count at a point in an orchard, and a load out is pallets on and pallets short. When the software's primary object is a single colony, every count becomes an aggregation somebody has to perform, usually at 2am with a headtorch, and it will not be performed accurately.

The consequence shows up twice. In reconciliation, because the office number and the field number drift with no event trail explaining where. And in commitments, because a yard that quietly went from 96 hives to 71 still reads 96 when you commit those hives, and you discover the shortfall on the truck.

The fix is to make pallet, yard, block and load first class objects with an append only movement log. A drop records pallets and hives on those pallets at that point, signed by the crew member, with location and timestamp captured automatically because nobody types a location correctly at night. Every count is an event rather than an edit, so the current number is derived and the history stays intact. When a yard count changes you can see exactly which visit changed it and who was there.

What goes wrong when you move yard lists and agreements out of notebooks?

Most of what you need to migrate was never written down in a form anything can read, and the parts that were are inconsistent in ways that only matter once you rely on them.

Yard names are the first problem. The same location is Miller Ranch in the spreadsheet, the Miller yard in a text message and the north forty to the crew who works it, and there is a second Miller a hundred miles away. Coordinates, where they exist at all, are pins in somebody's phone at the truck rather than at the drop. Landowner agreements are frequently verbal, with terms remembered differently by the owner and by the operator, and renewal dates nobody tracks.

Hive counts are the second. The count in the spreadsheet is a plan, updated when somebody remembers, not a record of anything observed on a date. Importing it as though it were an observation gives your new system a false starting position and every variance afterwards is measured from a number that was already wrong.

What works: treat the first season as the migration. Build the yard list with real coordinates captured at the drop, not from the spreadsheet. Establish opening hive counts by physically counting during the first move rather than importing, and mark them as an opening balance so nobody mistakes them for history. Capture landowner terms as they come up, yard by yard, and accept that the list will be incomplete for a year. Anyone proposing to import your spreadsheet and go live has not understood what the spreadsheet actually is.

Why do offline sync and the field app break after launch?

Offline is not an edge case in this business, it is the normal condition. Orchards and rangeland yards have no coverage, crews work at night, and several phones will edit the same yard before anything reaches a server. A design that treats offline as a fallback will fail in your first almond season.

The specific failure is silent and it destroys counts. Two crew phones both record activity at the same yard while out of signal. On reconnect, a last write wins strategy discards one of them, and the yard count reflects only one crew's work. Nobody sees an error. The number is simply wrong, and it stays wrong until a physical count months later disagrees with it.

The second failure is photographs. Grading evidence is worthless if the images did not upload, and an upload that fails quietly on a truck with one bar leaves a grade record with no photographs attached. You find out when you need it.

The third is language. Many crews work in Spanish, and a partly translated app gets used wrong rather than not used, which is worse because the data looks complete.

What to build: event sourcing with idempotent uploads so two devices merge rather than overwrite, and a visible queue on the phone showing what has not yet landed so a crew leader can check before leaving signal. Photographs queued with the same guarantees and a per record indicator that evidence is complete. Full translation of every field screen, tested with the crews who will use it, not with the office.

What happens when treatment intervals and movement paperwork are not covered?

Two obligations sit outside what any hive record app manages, and both convert into real exposure.

Treatments first. Miticide labels carry restrictions, including on use when honey supers are present, and applications need recording by yard, by date, by rate and by applicator. The failure is not usually the logging, it is the enforcement. A yard treated on the fourth is pulled on the twelfth by a crew that did not know, because the knowledge lived with the person who applied it. Feed records have the same shape. When a packer or a buyer asks about a specific lot, a season of recollection is not an answer.

Movement second. Hives crossing state lines generally require an apiary inspection certificate, and the requirement, the validity period and the inspection process differ by state, so an operation running almonds, then a northern flow, then southern build up deals with several regimes in one year. Improvising that paperwork is normal right up until a load is held.

What to build: treatments recorded against yards and pallets with product, registration number, lot, rate and applicator, propagating a state onto everything in the yard. Then a hard stop on a pull or a load out that would breach the interval you configured, overridable by a supervisor with a recorded reason. Yard records carrying the landowner, agreement terms, permitted hive count and renewal date. And a movement check when a cross state load is planned, telling you which certificate applies, when the current one expires and which hives it covers, with the documents attached to the load so a roadside question is answered from a phone. Confirm the current requirements with each state apiarist, since they change.

Should you build custom or configure what you already own?

Below roughly 1,500 hives, or where pollination is a minor part of your revenue, do not build. HiveTracks costs very little and covers hive records properly at that scale, and a disciplined spreadsheet covers the rest. The money belongs in equipment. If what you actually want is in hive sensing and pollination analytics, BeeHero is a different proposition and buying that capability is far cheaper than building it.

Push what you own further first. Most operations using a hive record app are using a fraction of it, and structured inspection capture alone removes a surprising amount of the notebook problem. If your issue is that inspections are inconsistent, that is configuration and training rather than a build.

The build case starts when the problem stops being records and becomes reconciliation, logistics and contract evidence. Build when two or more hold. You move more than about 5,000 hives between states each year. Your contracts pay on graded strength and you have lost an argument you believed you should have won. Office and field hive counts disagree by more than a few percent at any given moment. Crews who are not the owner do the counting, so operating knowledge needs to live somewhere other than one head. Or you run both pollination and honey production and cannot say which funds the other.

How do hidden costs get into the quote?

Offline first mobile is the item most often underpriced, because it looks like a feature and behaves like an architecture. Doing it properly means event sourcing, idempotent uploads, conflict merging and a visible sync state, and it touches every screen in the field app rather than sitting in one corner of it.

The others, in rough order. Multi language field applications, which is translation plus testing with real crews and maintenance as screens change. Honey extraction and drum lot tracking, which is a small manufacturing system and does not belong in a first release. Broker relationships, if brokers want their own reporting in their own format. Pallet tagging with barcodes or radio tags, which adds procurement, ruggedisation and replacement to your operating cost. And accounting integration, straightforward for invoices and awkward once you want cost allocated to yards and loads.

What keeps the number down: one season and one contract type. Almond delivery season alone will teach the build more than six months of specification documents, and everything you learn there applies to the rest of the year.

What separates a build that works from one that fails here?

Ask them to model your data on a whiteboard before anyone signs. The shape you want is pallet, yard, block, load, movement event, grade event, treatment event and contract line. If they draw hives and inspections, they have built a hobbyist app in their head and you will pay for the rewrite.

Ask specifically how offline conflicts resolve when two crew phones both edited the same yard out of signal. The honest answer involves event sourcing and idempotent uploads. Last write wins will lose you counts and the loss will be invisible.

Ask what the grading screen looks like at 2am with gloves on. The right build forces a photograph per graded hive, samples at your contract rate, computes the load average with its distribution rather than a single number, and generates the delivery record automatically so it reaches the grower or broker within hours of the drop. That timing is the whole point, because a record that exists before anyone has a reason to remember differently is what changes the outcome.

Then settle ownership before kickoff: the repository, the cloud accounts and the data. At Digital Heroes the client owns the code from the first commit. In an operation where the season is the year, being stuck waiting on a single vendor in February is a risk worth refusing.