Vertical Farming Operations Software: Why Yield Per Square Foot Never Traces Back to a Recipe

Why nobody in the building can explain a yield change

Room three drops eleven percent on a leafy green cultivar over two cycles. The head grower has a theory about the new seed lot. The engineer has a theory about a fan that has been running at reduced speed since a maintenance visit. Operations thinks the transplant crew was short two people that week and spacing slipped. All three theories are plausible and none can be tested, because the climate history lives in the Priva or Argus system, the seed lot is on a paper receiving sheet, the crew hours are in a payroll export, and the harvest weight is in a spreadsheet keyed by date and room rather than by batch. The investment case for the whole facility rests on yield per square foot, and the operation cannot attribute a change in it.

The stack is consistent across the sector. A control layer from Priva or Argus running climate, irrigation, and fertigation, sometimes a lighting controller from a different vendor, an advisory product such as Source.ag if you are in glass, a spreadsheet for the production plan, a task list in a general project tool, a food safety binder, and an accounting system that knows the electricity bill as one line per month. The control vendors are good at what they do: keeping a room at setpoint reliably is genuinely hard engineering and they have decades of it. What they do not do, and do not claim to do, is run your operation. They own setpoints. Your business runs on batches, tasks, labour hours, and harvests.

The cost of that gap in the facilities we have built for is threefold. Experiments that never conclude, because a recipe change was applied to a room rather than to a tracked batch and the comparison group does not exist. Labour that is managed as a weekly total instead of a cost per tray, in an industry where labour and energy are the two numbers that decide whether the unit economics work. And a food safety record that is assembled by hand, which becomes an acute problem the first time a customer asks you to identify exactly which trays went into a specific case.

Problem 1: the crop recipe lives in a controller and has no version history

A recipe is a schedule of setpoints by crop stage: photoperiod and intensity, temperature day and night, humidity or vapour pressure deficit, carbon dioxide, irrigation frequency, electrical conductivity and pH targets, and the timing of transitions between stages. In practice it exists as a program in the climate computer, which a grower edits directly. The edit has no author, no reason, and no version, and the previous state is gone.

What a custom build does: recipes become versioned documents in your system, with cultivar, stage schedule, targets, and an author and a reason on every change. Publishing a version pushes setpoints to the controller through its integration rather than a grower typing them, and the batch records which recipe version it ran under. Deviation is then measurable: planned versus actual conditions per stage per batch, which is the comparison that turns growing from craft into something you can improve deliberately. A grower can still override in the moment, because they should be able to, and the override is captured with a reason so it becomes evidence rather than noise.

Problem 2: the unit of yield is a tier, and the data is kept by room

A vertical farm's economics are per square foot, which means per tier, per zone, per position in the airflow. Yield is not uniform across a rack, and everyone who has run one of these facilities knows the bottom tier or the end of the row behaves differently. Yet almost all record keeping is per room and per week, which averages away the only variance worth studying.

What a custom build does: batches carry a location that is as precise as your operation can maintain, which usually means rack, tier, and tray position, with moves recorded as events when trays are spaced or shifted. Harvest weight and grade capture at the tray or tote level on a scale integrated station rather than typed at the end of the shift. Then yield per square foot resolves by tier and by position, and the facility engineer finally has data to argue with about airflow or light uniformity. In our experience this is the first report that changes a capital decision, because it converts a suspicion about a rack design into a measured difference.

The same location model does double duty for tasks. Seeding, transplanting, spacing, scouting, and harvest all target a batch at a location, which is what makes labour attributable in the next problem.

Problem 3: labour is the biggest controllable cost and it is invisible per task

Payroll knows hours by employee by week. The business needs hours by task by batch: how long transplanting a tray of this cultivar takes, how that changes with a new tool or a new crew, and what harvest labour per kilogram actually is by cultivar and by pack format. Without that, labour improvement is guesswork and every automation business case is built on an estimate.

What a custom build does: tasks are generated from the recipe schedule, so the day's work list is derived rather than written each morning, and each task is assigned, timed, and closed against a batch and a location on a phone or tablet at the rack. Labour cost then posts to the batch, and cost per tray and per kilogram becomes real. The second order benefit matters more than the reporting: because tasks come from the recipe, a recipe change automatically changes the labour plan, which means the plan and the crop stop drifting apart. Multi language support is worth building in from the start, since crews are frequently multilingual and a half translated task list produces wrong work rather than no work.

Problem 4: energy is the other decisive cost and it is allocated by the month

Lighting and HVAC dominate the energy bill, tariffs are frequently time of use with demand charges, and the facility's ability to shift lighting into cheaper windows is a real lever. Yet energy typically appears in the accounts as a monthly total and gets spread across production by weight, which tells you nothing about which cultivar or which room is expensive to run.

What a custom build does: sub metered consumption by room or by circuit, where the metering exists, joined to the tariff structure and to the batches in residence, so energy cost lands on the harvest. Once that exists, the lighting schedule becomes an optimisation with a constraint set: hit the daily light integral the recipe requires, avoid the peak demand window, respect the crop's photoperiod requirement. That is a genuinely useful piece of software and it pays continuously. It also requires the controller integration to be real and bidirectional, which is why it usually sits in phase two rather than phase one.

Problem 5: a customer asks which trays went into a case, and you cannot answer

Indoor growers sell into retail and foodservice buyers with audit programmes, and leafy greens sit squarely in the regulatory conversation around produce traceability. The FSMA Produce Safety Rule applies to covered produce operations and FSMA 204 traceability obligations apply to foods on the FDA Food Traceability List, which includes leafy greens, so confirm your specific coverage and the current compliance date with a food safety adviser rather than with a blog. Independently of the rule, your buyer's audit will ask for records you either have or do not.

What a custom build does: seed lot, substrate lot, and nutrient batch record at receiving and attach to the batch that consumes them. Sanitation and scouting records attach to zones with dates and personnel. Harvest to pack is a transformation event, so a case knows its parent batches, and a batch knows its cases and its customers. The recall query runs in both directions in seconds. Water testing and equipment sanitation schedules generate as tasks from the same engine that generates growing tasks, which is the difference between a food safety programme that is followed and one that is documented after the fact.

What this costs and how long it takes

Digital Heroes has delivered more than 2,000 projects, and for controlled environment agriculture the honest shape is as follows. A first release covering versioned recipes, batch tracking at zone and tier level, task generation with labour capture, and harvest capture with yield reporting runs $80,000 to $170,000 in 12 to 18 weeks. A full platform adding controller and fertigation integration, energy allocation and lighting optimisation, food safety records and traceability, and packing and order fulfilment runs $200,000 to $480,000 across 9 to 15 months.

What drives price up specifically in this category: controller integration, because Priva, Argus, and lighting vendors each expose data differently and some of it arrives through Modbus, BACnet, or OPC UA rather than a web API, and writing setpoints back is a higher bar than reading history. The number of distinct facility layouts, since a purpose built vertical farm and a retrofitted warehouse do not share a location model. Scale and packing line integration. Sub metering, which is sometimes an electrical project before it is a software one. And multi site scope, where cultivar recipes must be comparable across facilities that are not physically identical.

What keeps price down: one facility, three cultivars, and reading from the control system before attempting to write to it.

Build versus buy, and when buying is right

Do not build if you are running a single room pilot or a first commercial module still proving the crop. Spreadsheets plus your control system are adequate at that stage and the money belongs in lighting, airflow, and a good grower. If you are in glass and your question is crop forecasting and advisory, Source.ag offers something a custom build will not, because forecasting benefits from data beyond your own facility.

Build when two or more of these are true. You run more than one growing room and more than three cultivars. You are running recipe experiments and cannot conclude them. Labour is your largest controllable cost and you cannot state it per tray. You have investors or a board asking for yield per square foot by cultivar and the number is assembled by hand each month. Or a customer audit has asked you for a trace you had to reconstruct.

The tipping point is that control vendors sell you a room that holds setpoints, and your business is a production system that turns seeds, labour, and electricity into cases. Nobody sells the second thing, because it is shaped like your facility and your crop plan, and those are not standard.

How to choose a developer for a CEA operations build

Ask how they would integrate with your specific control system, by name. If the answer does not include the words Modbus, BACnet, or OPC UA, or a specific vendor API, they have not done industrial integration and your project will discover that in month three.

Ask them to model a recipe change mid cycle. The right answer is versioned recipes, batches bound to a version, and deviation measured against the version in force at each stage. A developer who models the recipe as a settings screen has built a configuration page and lost the ability to explain any yield difference.

Ask who owns the code, the infrastructure, and the historical data, and settle it in writing before kickoff. Your yield and recipe history is the asset that makes the next facility cheaper to commission, and it should not sit in a vendor's account. At Digital Heroes the client owns the code from the first commit and the data is exportable in an open format on request.