Greenhouse and Nursery Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why do grower builds get modelled as retail inventory?

The scope failure that defines this category is agreeing to build inventory software without settling what a unit is. Every developer arrives with a mental model of products, quantities and warehouse locations, which is fine for a distributor and wrong for a nursery. Twelve weeks later you have a competent stock system with plant names in it and no way to represent the events that actually change your position.

Growing is a sequence of transformations, not movements. A crop is stuck, potted up, spaced across two houses, graded, downgraded to seconds, consolidated with a later batch, and sold in three container sizes, with half a lot moving outside while the rest stays under cover. None of that is expressible as a quantity on a shelf, which is why the real system of record is a workbook with a version number in its filename.

The fix is to settle the model on a whiteboard before a single screen is designed. A crop is a production intent. A lot is a physical batch with a taxon, container size, grade, location down to bay or bench, a source and a cost roll. A sellable unit is a projection off the lot at a point in time. Splits, merges, spacing moves and grade changes are lot events that carry cost with the units. Ask a candidate to draw a lot splitting across two houses with half of it grading out, and to say what happens to cost. If they cannot articulate the difference between a crop, a lot, a location and a sellable unit, they will build you a retail system with botanical names.

What goes wrong when you migrate crop history out of your current system?

The export runs. The data does not mean what you think it means. A decade of loose naming leaves the same variety recorded several ways, sizes written as three gallon, 3g and #3 in one column, and abbreviations that made sense to a buyer who left in 2018. Import that unresolved and every downstream forecast treats one variety as several, which quietly destroys the thing you migrated the history for.

The second problem is that the valuable part of the history is often the part that was never recorded. What a finish-date model needs is stick date, actual first sale, actual ready date and yield against stick count, and most systems captured the plan rather than the actual. So you migrate a table of intentions and discover in month four that there is nothing to train on.

The fix is to budget migration as its own workstream, split three ways. Normalise taxon and size naming by hand against a controlled vocabulary before anything is imported, because tools can suggest matches but a person has to decide which are genuinely the same plant. Import crop cycle history where actuals exist and flag the rest as plan-only, so nobody trains a model on intentions. And establish the opening lot position from one physical count with the new mobile tool, rather than seeding from book quantities that already carry the error you are removing.

Why do accounting, environmental and trading partner integrations break after launch?

Three integrations matter and each fails differently. Accounting fails on ownership: somebody lets both systems write the same field, so a price or a customer record drifts and nobody can say which side is right. Environmental fails on silence: a feed from a climate controller stops delivering, and because nobody looks at raw environmental data daily, the gap is only discovered when a shrink investigation needs the week that is missing.

Electronic data interchange with a large retail program fails on assumptions. Each trading partner interprets the order, shipment and invoice transaction sets its own way, adds its own labelling and pallet requirements, and runs certification on its own calendar. A build that treats it as one piece of work will pass its own tests and then sit waiting in a partner's queue. After launch, the recurring failure is a spec change announced through a channel nobody monitors, so acknowledgements start failing during your peak weeks.

The fix is the same discipline in three places. Decide field by field which system is authoritative and never write it from both directions, keeping the general ledger firmly out of scope because nobody has ever been glad they built one. Monitor expectations rather than errors: alert when an environmental feed delivers fewer readings than its normal band, when a trading partner acknowledgement rate drops, or when orders arrive without a matching shipment confirmation. And name a person who owns each partner relationship, since certification and spec changes are relationship work.

What happens when compliance and fill rate obligations are not covered?

Two gaps recur. The first is shipping compliance. If you move plants across state lines you need nursery certificates and quarantine restrictions such as boxwood blight or sudden oak death modelled against your lots and destinations, not stored as a template somebody fills in. Scoped late, this becomes a retrofit into a model that never anticipated a lot being ineligible for a destination.

The second is the program penalty. A retail program with fill rate obligations turns availability accuracy directly into cash, and a system that can compute availability but cannot warn you early does not help. The failure is always timing: you learn you are short at the loading dock at four in the morning, when the only options are a broker at a punitive price or a chargeback.

The fix for compliance is to attach eligibility to the lot and enforce it at order entry, so a destination a lot cannot legally reach is rejected when the order is taken rather than when the truck is loaded, with certificates generated from the lot record. The fix for fill rate is a shortage workflow with lead time built in: when projected sellable drops below committed for a delivery week, fire an alert with enough runway to buy in, substitute or call the customer, and record which swaps each customer has historically accepted.

Should you build custom or configure what you already own?

If you are single-site, under roughly five to eight acres under cover, shipping under about five million dollars, with fewer than two hundred active items and no large retail programs, keep the system you have. The horticulture packages on the market will genuinely hold an operation that size, and if your current setup feels broken the cause is far more likely to be counting discipline and receiving process than software. A custom build will not fix a nursery where nobody counts.

Configuration deserves a real attempt above that too. Many growers have never used the reason codes, custom fields and scheduling capability they already pay for, and tightening receiving alone removes a large share of the errors that corrupt everything downstream. Build when at least three of these are true: you are multi-site and the sites do not share a location model; unexplained shrink is above ten percent and you have no mechanism to attribute it to a cause, a house or a decision; you run two or more programs with fill rate penalties; someone spends more than five hours a week rebuilding a number the system already claims to hold; your head grower's memory is a single point of failure; or you bought a module and your team stopped using it within a season, which is the clearest signal of all.

Even then, the hybrid is usually right and almost nobody proposes it. Keep accounting where it is, keep the incumbent as the financial and order backbone if it works there, and build the grower-facing layer of mobile inventory, live availability and shrink attribution on top.

How do hidden costs get into the quote?

Offline capability is the omission that hurts most. Greenhouses put concrete, steel and wet plastic between your crew and the access point, so an application that needs connectivity at the bench is abandoned within a fortnight. Building offline-first with a stated conflict rule adds a real percentage on top of a connected-only application, and a quote without it is quoting a product your growers will not use.

The rest of the pattern: multi-site with a mix of glass, field and container yard, which forks both your location hierarchy and your counting method; trading partner integration priced as one item when it scales per partner; migration of a decade of crop history, which is weeks on its own; older or proprietary environmental controllers, which may need a broker in the middle; shipping compliance if you cross state lines; and tag printing hardware. Training is quoted once for a workforce that turns over seasonally, which makes it annual.

The fix is to insist the vendor names counts before naming a price: sites and their physical types, acres and bench positions, active items, trading partners, whether you ship interstate, which controller you run, and how many people will use the mobile tool in a peak week. A quote that ignores those numbers returns as change orders during your busiest weeks.

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

The builds that pay back start narrow and attack the number you cannot currently see. Bench-level inventory with mobile counting, live availability computed as a ledger rather than a stored figure, and structured shrink capture. That is one problem solved end to end, and everything else depends on it being right.

Shrink capture is where the return actually comes from, and it lives or dies on structure. Every write-off needs a cause your growers recognise, not a generic reason code: cold damage, heat stress, disease pressure with the pathogen named, irrigation failure, mechanical damage, grade-out, overgrown, customer reject. Tie it to a location down to the bay, a crop cycle and a date, then join it against the environmental history you already collect and discard. Within a season you stop having one unexplained number and start having three fixable problems.

Respect the fact that your season is a cliff. Ask a prospective vendor when they would freeze deploys. A team willing to push code during your peak weeks does not understand that most of your year's revenue arrives inside a short window. The right shape is building in your quiet months, training in autumn, going live in winter, and running parallel through one full spring.

Finally, get code ownership and a documented schema handover into the contract before the first invoice, with the repository in your organisation and the hosting accounts in your name. A vendor who holds the code and licences it back is selling you another off-the-shelf tool at a bespoke price.