Custom Harvesting Operator Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the rate card get modelled as a single number?

Because almost every software category adjacent to this one bills one way, and whoever writes the data model reaches for the pattern they know. Field service software bills labour and parts. Trucking software bills a rate per mile. Farm management software does not bill at all, because it assumes you own the crop.

You do not bill one way. A single farm can carry a per acre rate, a per hour rate for the down wheat, a bushel adder over a yield threshold, a hauling charge that may be per bushel or per bushel mile, a move charge, a minimum, and waiting time when the trucks the grower promised did not turn up. That is not an exceptional job. That is Tuesday.

The scope failure is subtle because it looks like it worked. A system that models one basis and treats the others as adjustments will demo beautifully and then fail in July, when an operator standing in a field cannot record what actually happened without a note in a comment box. The moment a note in a comment box becomes load bearing, the spreadsheet comes back, and now you are running both.

Model all three bases as first class on the job object from the first release, with thresholds, minimums, move charges and waiting time as structured fields rather than adjustments. Add rate cards per customer with effective dates, because you quote in winter and cut in July and the rate that applies is the one agreed. That first release, with offline job capture, mixed basis rate cards and a settlement statement, runs $40,000 to $95,000 and ships in ten to fourteen weeks. Everything else can wait.

What goes wrong with the job records and scale tickets you rely on?

The data problem in this business is not migration from an old system. It is that the record was never captured in the first place.

Acres come off a monitor that has been reset since. Hours come from a memory of when the machine started. Moisture and dockage sit on a paper scale ticket in a truck door pocket, and the ticket proving the bushel adder is the one that got rained on. Downtime is remembered as roughly two days. Every one of those is an input to money you are owed, and every one is reconstructed rather than recorded.

So capture quality is the whole project and everything downstream is arithmetic. Field capture has to happen in the cab, has to work with no signal because a wheat field in the panhandle has none, and has to be fast enough that an operator does it at the end of a round rather than the end of a week. Acres started and finished, machine, operator, start and stop times, downtime with a reason code, moisture readings, and a photograph of anything likely to be disputed.

Scale tickets deserve their own handling. Photograph the ticket at the elevator, capture gross, tare, net, moisture and dockage as structured fields, and tie it to both the job and the truck, so a per bushel charge is computed from a document rather than a conversation. Keep the photograph attached permanently. When a grower questions a bushel adder in September, the ticket image and the extracted figures side by side end the discussion in a minute.

Why does machine telemetry disagree with the operator after launch?

Because monitor acres and mapped acres are measuring slightly different things, and every mixed fleet produces a different flavour of the difference.

Headland overlap, partial passes, whether the header was engaged, how a monitor handles a point turn, and where calibration sat when the machine came off the truck all shift the number. The platforms behind the major manufacturers expose data differently, so the same field cut by two machines produces two figures that are both defensible and not equal.

The build failure is deciding that one source wins silently. If telemetry overwrites operator entry, an operator who knows the monitor was reading light stops trusting the system and goes back to a notebook. If operator entry always wins, you have bought telemetry for nothing.

Build a mapping layer per brand into your own machine hour and acre record, keep operator entered figures alongside it, and reconcile the two rather than resolving them. A weekly variance report showing where monitor acres and entered acres diverge by more than a tolerance is genuinely useful information about calibration, operator practice and field conditions, and it is worth more than either number alone.

One commercial point belongs in the design rather than a contract review. Data access terms are the manufacturer's to change, so never let the system depend on any one of them continuing to grant access on current terms. In practice that means operator entry has to remain a complete path rather than a fallback that has quietly rotted.

What happens when moves, crew hours and downtime are not covered?

They stay invisible, and invisible costs are where a capital business quietly loses money.

Equipment moves are the clearest example. The low boy, the permits, the fuel, the escort where required and the days the machines are not cutting are real and substantial, and most operations track them as nothing at all. Modelled as billable and costed events attached to the run, they change how you price a job at the edge of your range and whether you take it.

Crew hours are a payroll input and, where you run labour under the H-2A programme, an obligation with documentation requirements attached. Hours by person by machine by day should fall out of the capture the operator is already doing rather than a second timesheet filled in on Sunday, because a second timesheet is always wrong and always late. Confirm the current requirements with your labour counsel, since programme rules change.

Downtime is the one that changes negotiations. Two days of a grain cart waiting on trucks the grower was supposed to supply is either a waiting charge you can substantiate or an argument you will lose, and reason coded downtime captured at the time with a start and a stop is the difference. It also feeds the analysis telling you which machine earns the least per hour, which decides capital allocation for the next season.

Should you build custom or configure what you already own?

Keep the spreadsheet if you run one combine and one truck across a couple of counties for a stable list of growers you have cut for a decade. Your settlement is already fast because your memory range is short, and a custom build would be an expensive way to formalise something that works. We would say that on a first call and have.

Before building, look honestly at whether an adjacent product covers enough. If almost all your billing is per acre with occasional adjustments, a well structured spreadsheet with a shared cloud copy plus a simple invoicing tool may hold for another season. If your business is mostly hauling with harvesting attached rather than the reverse, a dispatch product may fit better, because your revenue object is closer to a load.

Build when two or more hold. You run four or more machines or more than one crew. Your run crosses three or more states. You bill on mixed bases and your invoices are routinely questioned. You have written off differences you believed you were owed because you could not prove them. Or you cannot answer, today, which machine on your fleet earns the least per hour. That last one usually justifies the project on economics rather than administration, because a custom crew is a capital business pretending to be a service business, and capital allocation without cost per machine is guesswork.

How do hidden costs get into the quote?

• Telemetry brand count. Each manufacturer is a separate integration with its own authorisation flow, and a quote for one brand does not extend to three by configuration.
• Hauling complexity. If you run your own trucks and settle per bushel mile, the distance basis, the ticket matching and the truck level costing are meaningful additional scope.
• Payroll integration. Fiddly in general and more so where H-2A labour brings its own documentation requirements, which are a compliance obligation rather than a report.
• Offline handling. Priced as forms and delivered as a synchronisation problem, particularly the case where two devices edited the same job before either had signal.
• Devices and mounting. Tablets that survive a cab in July, mounts, charging and a replacement rate, plus the reality that some operators will use their own phones.
• Timing. Attempting to roll out during a run costs you the harvest rather than the project. Starting in the off season is cheaper than it looks because nothing has to be done twice.

What holds it down is narrowing the first release to one crop and one billing pattern. Trying to model every service you offer before shipping anything is how these projects miss a season.

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

Ask a prospective developer to model a job on a whiteboard that bills partly per acre and partly per hour, with a bushel adder over a threshold and a waiting charge, before you sign anything. If they reach for a single rate field with adjustments, they will build an invoicing tool you abandon in July.

Ask what happens with no cell signal for a full day and two devices editing the same job. Anyone who has built for agriculture raises that without being prompted, and the answer should be a decided conflict rule rather than an assurance that it will not happen.

Ask how they will handle telemetry from two different manufacturers and what happens when one changes its data access terms. The answer should be a mapping layer you own plus operator entered figures as a complete parallel path, never a hard dependency on any one manufacturer.

Insist the first release produces a settlement statement a grower can read, itemising acres, basis, adders, hauling and adjustments, on the day the crew leaves the farm. A proposal that defers settlement to phase two has deferred the reason for the project.

And settle ownership in writing before kickoff: the repository, the cloud accounts and the unrestricted right to bring in another firm. At Digital Heroes the client owns the code from the first commit. In a category with no packaged alternative, being unable to change your own system between seasons is not an inconvenience, it is a business risk.