Before buying autonomous growing software on the strength of a profit score, ask what earns that score. Does it reward the product your buyer accepts, include the costs your business pays and account for the people who still make the crop work?

A benchmark can be accurately calculated and still answer a different commercial question. The purchasing task is to connect the software’s objective to a specific accepted product and a realistic operating arrangement before using the result as evidence of value.

A higher score with less fruit per pot

A 2025 paper by Maree and colleagues describes WUR’s autumn 2024 dwarf-tomato experiment in Bleiswijk, the Netherlands. Six algorithms each controlled one 96 m² compartment. Reference was also an algorithm; there was no human-grower control. Final crop measurements used 50 central plants per compartment as subsamples.

Two reported rows from the Dutch dwarf-potted-tomato trial
AlgorithmMeasured ripe red fruit, g/potCultivation, daysAverage density, pots/m²Calculated trial score, EUR/m²/day
IDEAS2197039.70.34
Reference2757425.30.13

The score used fruit weight and dry matter to assign value, together with stipulated costs and area/time accounting. It did not fully include commercial harvesting, transport, labor, insurance or investment. These are computed trial scores, not measured farm net profits. One compartment per algorithm and one crop cycle do not establish a generally superior commercial service.

The comparison is useful because grams per pot and value per occupied area over time answer different questions. Higher density can change the latter without increasing the former. A buyer needs to know which outcome matters for the product being sold, rather than treating any improvement in the displayed score as a complete business improvement.

Make product acceptance part of the objective

The trial valued fruit measurements rather than the usual ornamental value of the potted plant. The authors also described stretching, instability and difficult plant movement. Manual spacing, harvest, scouting and equipment support remained part of the operation.

Consider a hypothetical buyer who needs uniform potted plants that can be moved and presented without damage. A software proposal optimized mainly for fruit value per area and time could encourage a crop that scores well while creating extra handling work or an unsuitable plant form. The test should therefore include those acceptance conditions before the crop is grown.

The same purchasing logic can apply to a high-wire tomato business, but the Dutch pot densities, euro scores and crop response cannot simply be transferred to it. Define the high-wire product and production cycle on their own terms.

A blank growing-software scorecard reviewed alongside a potted tomato, crop-quality checklist, area and time notes, cost ledger and manual-work tools
Conceptual illustration

Ask the supplier to explain one successful run

Choose a complete benchmark run and have the supplier walk through it in ordinary business terms:

  • What was sold or valued? Distinguish actual accepted sales from a value assigned by a research formula. Identify grades, pack requirements, rejected product and any quality conditions outside the score.
  • What space and time were counted? Check whether the denominator represents occupied growing area, whole-house area or a different boundary. Confirm the start and end of the crop period.
  • Which costs were included? Separate measured resource use, assumed prices, service fees and costs omitted from the benchmark. Avoid treating a narrowly defined score as the farm’s complete accounts.
  • What did people still do? Name routine crop work, scouting, equipment care and exceptional interventions. Agree who provides them for the proposed service.
  • What evidence transfers to this crop? Ask which product, season and operating conditions have actually been demonstrated and which remain to be tested.

This conversation should produce an acceptance objective the grower and supplier can both recognize. A result that relies on a different product or hidden support work may still be informative, but it needs a clear bridge to the proposed operation.

Agree what success must look like before purchase

Write down the accepted product, the operating period, the score’s cost boundary and the retained human responsibilities. Then require evidence under representative conditions, including a record of interventions. Keep any claimed labor saving separate until actual tasks and avoidable work have been assessed.

A sensible outcome may be to revise the objective or run a limited acceptance evaluation before committing more crop area. It may also be to accept the software when its evidence matches the business requirement. The point is to make the commercial test explicit, rather than letting the benchmark’s label define success.

Use automation system commissioning for the separate hardware and control checks. Here, the decisive question is whether the software is being rewarded for an outcome the greenhouse can actually use.