Agronomy Consulting Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does renting field boundaries from grower platforms happen so often?

Because the boundaries already exist in the grower's account, importing them is free, and drawing 900 fields yourself sounds like a waste of a season. So the firm pulls from John Deere Operations Center or Climate FieldView and gets moving.

The problem is that everything in your business hangs off that boundary. Acres billed, rates applied, zones sampled, prescriptions written, records retained. If the boundary lives in an account you do not control, held by a grower who may switch platforms or switch consultants, then your business records depend on someone else's subscription. Every spring your agronomists spend the first three weeks redrawing or reimporting because a farm picked up rented ground, split a pivot or dropped a landlord, and the three versions in circulation, yours, the grower's and the one the crop insurance agent uses, disagree on acres.

The cost shows up twice. In April as unbillable rework, and in November when a grower questions an invoice and you cannot produce the boundary the acreage came from.

The fix is to treat boundaries as versioned, dated records you own, with lineage when a field is split or merged, and acreage computed from geometry rather than typed. Versioning looks fussy and turns out to be essential, because a 2024 recommendation has to be reproducible against the 2024 boundary even after the field changed shape in 2025. Synchronisation with grower platforms then becomes an exchange you control rather than a dependency.

What goes wrong when you migrate boundaries and season history?

Two failures, and both come from importing shapes without deciding what a field is.

The first is identity. A grower's platform holds a field called North 80 that was split in half when 40 acres went to another operator in 2023. Your records reference both the original and the two halves, in different seasons. Import them as three unrelated fields and the history breaks: last season's soil results attach to a field that no longer exists, and this year's scouting attaches to a shape with no past. Import them as one and the acreage is wrong for at least one season.

The second is acreage provenance. Firms migrate a typed acres figure because that is what the contract used, and then compute acreage from geometry going forward. The two disagree, sometimes by several percent on irregular ground, and the first grower who notices asks why his bill changed when nothing about his farm did.

What works: model split and merge lineage explicitly so a field can point at what it came from, migrate season by season rather than as a single snapshot, and when contract acres and computed acres differ, hold both with the difference visible rather than picking one silently. Then have the awkward conversation with growers once, before go live, rather than one at a time across a billing cycle.

Why do the platform and laboratory integrations break after launch?

Prescription delivery breaks because a file that will not load at 6am is a file that did not happen. Different controllers interpret rate units and zone boundaries differently, so a prescription tested only against a sample file behaves unpredictably in a cab. An applicator who cannot load it spreads a flat rate and tells nobody, which means your advice was not followed and your record says it was.

Platform integrations break because each grower platform models a field differently, so a sync written against one shape drifts when the other side changes. Nothing errors. The boundary you push and the boundary they hold simply stop matching.

Laboratory ingestion is the sleeper. Every lab exports its own layout, and normalising nutrient names, units and extraction methods across four labs is genuinely fiddly. A change to one lab's export format silently maps phosphorus into the wrong column, and the recommendations built on it are wrong in a way nobody spots for a season.

The fixes are the same in each case. Export in several formats, meaning ISOXML for equipment following ISO 11783 and shapefiles for legacy controllers, and test against real equipment rather than assuming. Record delivery: which file went to which operator at what time, and whether an as applied record came back. Put a schema check on every laboratory feed so an unexpected layout fails loudly rather than mapping into the wrong field. And reconcile boundaries with grower platforms on a schedule, with differences raised as tasks.

What happens when pesticide records and label constraints are not covered?

The records are your obligation and your defence, and they are almost free if the recommendation is built properly. Left out, they are reconstructed under pressure from notes.

In the United States, certified applicators must retain restricted use pesticide application records, with a federal minimum retention of two years and states frequently requiring more. Worker Protection Standard restricted entry intervals and pre harvest intervals have to be respected and, where you made the recommendation, evidenced. Nutrient management plans carry their own state and programme rules. Confirm the exact requirements for the states you operate in with your state lead agency or an agronomic compliance specialist, because they genuinely differ and software vendors are not a reliable source for this.

The specific failure is treating products as free text. If the product on a recommendation is a typed name, the system cannot check anything. If it is a real record with EPA registration number, label rate range and interval constraints attached, the system can refuse a rate outside the label range and warn when a pre harvest interval conflicts with the grower's expected harvest window. That check is worth building in the first release, because it prevents the category of error that becomes a liability claim rather than a correction, and it turns compliance packs into an afternoon's export per grower per season.

Should you build custom or configure what you already own?

Under roughly 10,000 consulted acres with one or two agronomists, do not build. Agworld handles scouting and recommendation workflow well, Agrian is strong on product labels and compliance, and a spreadsheet handles billing at that volume. A per acre subscription is far cheaper than a build plus its maintenance, and we would say so rather than quote.

Be precise about where those products stop. Agworld and Agrian solve real parts of this, and Conservis is a capable operations and financial product on the grower side. What none of them holds is the join a consulting business runs on: a boundary that is yours, a recommendation that is a signed professional document, the prescription that came from it, the application that was actually made, and the invoice line all of that produces.

Build when two or more of these are true. You consult on more than about 40,000 acres and your agronomists spend the first three weeks of spring fixing boundaries. Per acre billing cannot be reconciled to evidence of work performed. Your service catalogue runs to more than about six billable service types with pricing that varies by grower. Reproducing a two season old recommendation took days. Or you have a genuine operational advantage, such as a proprietary sampling protocol or a zone modelling method, that a generic platform flattens into its own workflow and quietly commoditises.

How do hidden costs get into an agronomy software quote?

Five lines, and three of them get deferred to phase two once someone prices them honestly.

Grower platform count, because each integration is real work and their models of a field differ, so two platforms is not one integration done twice.

Laboratory ingestion, where four labs means four layouts plus the normalisation of nutrient names, units and extraction methods.

Prescription export, since controller compatibility has to be tested against actual equipment rather than assumed, which means access to machines and applicators during the build.

Multi state compliance, where each state's requirements become their own configuration.

And the grower portal, which is a second product with its own support burden and should only be built when growers have asked for it twice. Against those, the honest shape is $50,000 to $110,000 over 10 to 14 weeks for a first release covering owned versioned boundaries, offline scouting, immutable recommendations with signature and per acre billing tied to evidenced work, then $130,000 to $320,000 across 6 to 12 months for the full platform.

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

Scoping the first release as the business rather than as the technology. Boundaries, scouting, recommendations and billing. Prescriptions and laboratory ingestion are next season's work once the record is solid, and firms that reverse that order end up with excellent prescription tooling sitting on billing they still cannot defend.

Scouting that survives four hours with no coverage, because that is a normal day. Offline capture with photographs that keep their location attached to the observation, and sync that does not lose a note when the phone dies.

Recommendations that are immutable by design. Fields and acres covered, product and rate, the observation that justified it, the agronomist and their certification, and the grower's acceptance where you capture it. Amendments become new versions linked to the original rather than edits. This is the feature that changes the character of the business, because it converts advice from a conversation into a record.

Billing tied to evidence rather than to contract. Each billable event points at the scouting visit with its timestamp and location, the recommendation with its acreage, the sampling job with its point counts. Contracted acres against serviced acres becomes a live variance in July instead of an argument in November.

And ownership of the code, the cloud accounts and the boundary data in writing before kickoff. The entire point of the build is to stop renting your own field records from a platform, so accepting a new dependency from your developer would defeat it.