Commercial Beekeeping Software: Proving Frame Strength When the Grower Argues

Why hive records become contract arguments

It is the second week of February in the Central Valley. Your crews set 4,200 hives into almond orchards over nine nights, four to a pallet, forklift off the semi, drop points recorded as pins on somebody's phone. Ten days later the grower's third party grader walks a sample and reports an average frame count below what the contract specifies. The grower wants a price adjustment on the whole block. Your evidence that those hives went in strong is a beekeeper's memory, a few photos in a camera roll, and a notebook in a truck cab with yard names that mean something only to the crew that wrote them. The contract is worth six figures. The argument is settled by whoever sounds more certain.

The tool stack in these operations is usually a mix of HiveTracks or Nectar for inspection records, a spreadsheet for hive counts by yard, QuickBooks for invoicing, a shared phone album for photos, and a lot of text messages. Those tools are real and the inspection apps in particular have made field data capture much better than a clipboard. What none of them holds is the object your business actually runs on: a pallet, in a specific yard or block, on a specific date, with a graded strength, a treatment history, a queen status, and a contract line it is being paid under. Hive record apps model a hive. Your money is made and lost on pallets and loads.

The leak is concrete and it shows up in three places. Grade disputes you cannot rebut, which in our experience is the single largest recoverable amount in a migratory operation. Losses discovered late, because a yard nobody visited for five weeks has quietly gone from 96 hives to 71 and the count in the spreadsheet is still 96 when you commit those hives to the next contract. And treatment records that cannot be produced cleanly when a buyer, a state inspector, or a packer asks, which turns a routine question into a two day search through notebooks.

Problem 1: the unit of work is a pallet, not a hive

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 GPS point, and a load out is pallets on and pallets short. Yet almost every software model available starts from an individual hive with an individual identity, which is correct for a research apiary and wrong for a 20,000 colony operation.

HiveTracks is genuinely good at hive level records and inspection history, and it suits sideliners and smaller commercial outfits well. Nectar is built for field capture at scale and handles inspection data seriously. Neither is designed as an inventory system where a pallet is the primary object, moves between yards and blocks on dated events, and reconciles counts on and off a truck. That is warehouse logic applied to bees, and it is where the count integrity comes from.

What a custom build does: model pallet, yard, block, and load as first class objects with an append only movement log. A drop records pallets and hives on that pallet at that point, signed by the crew member, with GPS and timestamp captured automatically because you cannot rely on anyone typing a location correctly at 2am. Every count is an event, not an edit, so the current number is derived and the history is intact. When a yard count changes you can see exactly which visit changed it and who was there.

Problem 2: grading is a negotiation and you arrive without evidence

Pollination contracts commonly pay on average frames of bees, verified by a sample walk. The grade happens after your hives have been sitting in an orchard for a week or more, in weather you do not control, sometimes next to somebody else's weaker hives. If your position is that they went in at contract strength, you need to be able to show it at the moment of delivery, per pallet, with something better than a claim.

Inspection apps record strength assessments and are useful for that. What they do not produce is a delivery artifact designed to survive a commercial dispute: a per load grade summary, sampled at your stated rate, with photographs tied to specific pallets, GPS, timestamps, and the grader's identity, exported as a single document you can put in front of a grower or a broker the same day.

What a custom build does: a grading workflow that runs offline in the orchard, samples at whatever rate your contract specifies, forces a photo per graded hive, and computes the load average with its distribution rather than a single number. Then it generates the delivery record automatically and sends it to the grower or broker within hours of the drop, before anyone has an incentive to remember it differently. This is not a technical achievement. It is the practice of documenting at the point of delivery, and building it into the software is what makes it actually happen when crews are exhausted.

Problem 3: treatments, withdrawal, and residue records live in a notebook

Miticide labels carry restrictions, including on use when honey supers are on, and the products you apply have to be recorded by yard, by date, by rate, and by applicator. Feed matters too: what syrup or patty went where, and when. If honey from a yard is later questioned, the answer has to come out of a system, not out of a season's worth of recollection.

What a custom build does: treatments record against yards and pallets with product, EPA registration number, lot, rate, and applicator, then propagate a state onto everything in that yard. A pull or a load out that would violate the interval you configured for that product raises a hard stop that a supervisor has to override with a reason, and the override is logged. When a packer asks about residue, the query is one lookup and it takes minutes.

Problem 4: interstate movement and yard permissions are paperwork you improvise

Hives crossing state lines generally require an apiary inspection certificate, and the specific requirement, validity period, and inspection process differ by state, so an operation running California almonds, then a northern honey flow, then southern build up is dealing with several different regimes in one year. On top of that sit landowner agreements for yards, some written, many not, with different terms on rent, hive counts, and access.

What a custom build does: a yard record carrying the landowner, agreement terms, permitted hive count, renewal date, and access notes, plus a movement compliance check that fires when a load is planned across a state line and tells you which certificate is needed, when the current one expires, and which hives it covers. Documents attach to the yard and the load, so a roadside question or an inspector visit is answered from a phone. This is the part owners underestimate and then value most, because it converts institutional memory into something a new operations manager can run.

Problem 5: nobody knows which yards and which contracts actually make money

Revenue is easy: pollination contracts and honey sales. Cost is not, because the same crew, the same trucks, and the same feed serve both, and allocation is done once a year with a gut estimate. So the operation cannot answer whether the third almond contract at a lower rate is worth the trucking, or whether a honey yard that produces well is being carried by a yard forty miles further out that does not.

What a custom build does: cost objects that follow the work. Labour posts to yards and loads through crew time capture, trucking posts by mile and load, feed and treatment post by product consumed at the yard, and equipment depreciation posts per hive per season. Then margin appears per contract, per yard, and per mile band, and decisions about which contracts to renew stop being decided by relationships alone. Loss rate by yard, by treatment protocol, and by wintering location becomes visible in the same view, which is the number that quietly governs whether next season's contracts are deliverable at all.

What this costs and how long it takes

Digital Heroes has delivered more than 2,000 projects, and for migratory beekeeping the honest shape is this. A first release covering pallet and yard inventory with offline capture, grading with photo evidence, and treatment records runs $55,000 to $120,000 in 10 to 16 weeks. A full platform adding contract settlement, interstate movement compliance, honey lot traceability from yard through extraction to drum, and per yard profitability runs $140,000 to $320,000 across 6 to 12 months.

What drives the price up here specifically: offline first mobile, which is not optional because orchards and rangeland yards have no signal and crews work at night, and doing offline sync properly with conflict resolution is real engineering. Multi language field apps, since many crews work in Spanish and a half translated app gets used wrong. Honey extraction and drum lot tracking, which is a small manufacturing system in its own right. Broker relationships, if you place hives through brokers who want their own reporting. And RFID or QR pallet tagging if you want scanning rather than counting, which changes the hardware conversation.

What keeps the price down: starting with one season and one contract type. Almond delivery season alone will teach the build more than six months of specification.

Build versus buy, and when buying is right

Do not build below roughly 1,500 hives, or if pollination contracts are a minor part of your revenue. HiveTracks costs very little and covers hive records properly at that scale. BeeHero is a different proposition again, sensor led, and if in hive sensing and pollination analytics is what you want, buying that capability is far cheaper than building it.

Build when two or more of these are true. 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. Your hive counts in the office and in the field disagree by more than a few percent at any given moment. You run crews who are not the owner, so the operating knowledge needs to live somewhere other than one head. Or you run both pollination and honey production and cannot say which one funds the other.

The tipping point is the pallet. Once the operation is large enough that nobody can hold the yard map in their head, hive record software stops being the answer, because the problem has become inventory, logistics, and contract evidence. Those are different systems, and no beekeeping app is going to grow into all three.

How to choose a developer for a beekeeping operation

Ask them to model your data on a whiteboard before you sign. The right shape 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 be paying for the rewrite.

Ask specifically how offline sync resolves conflicts when two crew phones both edited the same yard while out of signal. The honest answer involves event sourcing and idempotent uploads, not last write wins. Last write wins will lose you counts.

Ask who owns the code, the repository, and the cloud accounts, and get it written down before kickoff. At Digital Heroes the client owns the code from the first commit. In an industry where a season is the whole year, being stuck waiting on a single vendor in February is a risk you should refuse to take.