Why Generic Software Fails Short Food Supply Chains: The Case for Vertical SaaS Built by an Operator

Why do ERPs and e-commerce platforms fail short food supply chains?

They fail at the data model, not the feature list. Generic platforms assume one seller owns the stock, the price and the money. A short food supply chain has forty owners of stock, one shared customer relationship, one shared van and one payment that must be split apart afterwards. No amount of configuration reverses that assumption.

An ERP is built around a company that buys inputs, holds inventory it owns and sells output. Its ledger has one balance sheet. A food hub often never owns the produce at all: it aggregates, sells on behalf, deducts commission and remits the rest. The transaction that matters is a settlement across many parties, and the ERP has no primitive for it beyond bolting on a supplier invoice run that assumes purchase orders and lead times nobody in local food uses.

E-commerce platforms fail from the opposite direction. They model a catalogue perfectly and a fulfilment operation barely. A shopper order in a food hub is not one shipment, it is a pick list split across producers, reconsolidated into one crate, assigned to a route, and reconciled twice: once against what the producer actually delivered to the depot, and once against what the driver actually handed over. Every one of those steps writes data that the storefront schema has nowhere to put.

The five data-model assumptions generic tools get wrong

Five assumptions break every time: single ownership of stock, inventory as a running count, one price per product, order equals shipment, and payment equals revenue. Each is reasonable for a retailer and structurally wrong for a multi-producer local food operation, which is why workarounds pile up rather than resolve.

The interesting part is that these are not edge cases you handle later. They sit at the root of the schema, so a fix in one place forces a lie somewhere else. Track stock per producer in a storefront's variant field and you lose the ability to sell 'carrots' as one product. Model producers as separate stores and you lose the single basket. Model them as suppliers and you lose the ability for a grower to log in and change their own numbers on a Tuesday night.

Single ownership of stock: generic tools assume the platform owns what it sells. A hub sells on behalf of producers who retain ownership until handover, which changes liability, VAT treatment and who absorbs a shortfall.
Inventory as a running count: perpetual inventory assumes goods exist in a warehouse. Most small producers declare what they expect to have for a specific delivery window, and the number is a promise, not a stock level.
One price per product: the same lettuce may carry a shopper price, a producer payout price, a restaurant price and a co-op commission, all changing per cycle, and all needing history for reconciliation.
Order equals shipment: an order splits across producers for picking and recombines into a single crate for delivery, so line-level fulfilment state and order-level delivery state are different objects.
Payment equals revenue: money collected at checkout is mostly other people's money. Until settlement runs, the platform holds a liability, not a sale.

What industry-specific edge cases actually look like

The edge cases are weather, biology and human availability. A grower declares 40 kilos of courgettes, hail arrives on Wednesday, and 12 kilos turn up. That single event has to cascade through the pick list, the shopper's basket, the substitution policy, the driver's manifest, the refund and the producer payout, without an administrator retyping anything into four systems.

Then there are the quieter ones. Weight-variable products where a shopper is charged for 1.2 kilos of a chicken they ordered as 'one chicken'. Returnable crates and deposits that must survive a customer who keeps them for three cycles. Pickup points where the pickup window, not the address, is the routing constraint. Batch and lot capture at the depot so a recall can be traced back to a specific harvest rather than a specific producer. Cash on delivery, still common in many local markets, which turns a driver into a payment collection point with all the reconciliation that implies.

None of these is exotic within local food. All of them are exotic to a horizontal platform, which means they arrive as consultancy hours, spreadsheets alongside the system, or a rule that exists only in one administrator's head. That last one is the expensive version, because it walks out of the door when they do.

Vertical SaaS versus horizontal SaaS: what actually differs

Vertical SaaS narrows the addressable market in exchange for opinionated defaults. A horizontal platform must stay generic to serve everyone, so it pushes domain logic into configuration, apps and services. A vertical platform ships that logic as the default behaviour, which is why setup takes weeks instead of quarters and why nobody needs an integration partner to explain a payout.

The practical difference shows up in three places. First, vocabulary: a vertical product calls things what the industry calls them, so training is shorter and disputes are clearer. Second, defaults: the correct behaviour for a shortfall, a substitution or a deposit is already chosen, and disagreeing is an override rather than a build. Third, the roadmap: improvements to route consolidation or settlement rules benefit every customer, because every customer has the same problem. On a horizontal platform, your industry's needs compete with every other industry for engineering attention, and local food is not the segment that wins that argument.

The honest trade-off is flexibility. If your operation genuinely is a single farm with a single storefront, a horizontal platform is cheaper and better. Vertical software earns its keep at the point where the second producer joins and the coordination cost, not the selling, becomes the job.

Why software built by an operator ends up different

Building and running the same operation changes what gets prioritised. When the team writing the settlement code also has to explain a payout to a grower who disagrees with it, rounding rules, dispute handling and payout statements stop being backlog items. They become the parts of the product that get attention first, because someone on the team feels the consequence within the week.

Plodie's team runs Plodovi.hr, a working short food supply chain in Croatia, alongside building the platform. That arrangement produces a specific kind of feedback loop. Features that demo well but fail at 6am in a depot with cold hands and poor signal get removed. Rules that producers ignore get deleted rather than defended. Reports get built because a co-op board asked a question that transaction data could answer and nothing in the system answered it yet.

It also changes what does not get built. An operator knows which problems are real and which are hypothetical, so the product avoids the trap of accumulating configuration options for scenarios nobody in the sector actually runs. The cost of this approach is that opinions are baked in, and a hub that works differently has to adapt or ask for a change. The benefit is that the defaults are drawn from an operation that has to survive Thursday's deliveries.

How to evaluate software for a multi-producer food operation

Test the model, not the demo. Ask the vendor to walk through four scenarios end to end: a producer shortfall after orders close, a shopper refund on one line of a multi-producer order, a settlement run with commission and deposits, and a recall traced from a customer back to a harvest batch. If any of those requires a spreadsheet or a support ticket, you have found the limit of the model.

Beyond the scenarios, a few structural questions separate a fit from a costly retrofit. Can producers change their own numbers without an administrator relaying them? Does the system distinguish between money held on behalf of producers and money the hub has earned? Is fulfilment state tracked per order line as well as per delivery? Can one producer never see another producer's figures, by design rather than by policy? Does the price a shopper paid stay attached to the order line after the price list changes?

Finally, ask who else uses it and what they do. A platform serving hundreds of unrelated industries will treat your requirements as a niche. A platform serving food hubs will have already argued internally about crate deposits. Neither answer is automatically right, but the second one means the hard conversations have happened before you arrive.

Key Takeaways

Generic ERPs and e-commerce platforms fail short food supply chains at the data model, not the feature list: they assume one owner of stock, one price and one shipment per order.
Multi-producer operations need line-level fulfilment, per-producer stock declarations, settlement as a first-class object and money held on behalf of others treated as a liability, not revenue.
Local food edge cases like shortfalls, weight-variable products, crate deposits, pickup windows and cash on delivery are routine in the sector and exotic to horizontal platforms.
Vertical SaaS trades flexibility for opinionated defaults, shared vocabulary and a roadmap where your industry is the only industry competing for attention.
Evaluate vendors by walking four scenarios end to end: a shortfall after orders close, a single-line refund, a settlement run with commission and deposits, and a batch-level recall.

For the single-vendor version of this argument in detail, see why Shopify breaks at the second producer, which walks through the six specific points where a single-merchant storefront fails a forty-grower market.

Frequently Asked Questions

Is it cheaper to customise an existing ERP or buy vertical food hub software?

Customising an ERP is usually cheaper on the licence line and more expensive everywhere else. The costs land in implementation consultancy, ongoing maintenance of custom modules, and the upgrade risk that comes with modifying core objects like inventory and receivables. Vertical software costs more per seat but ships the domain logic as standard behaviour, so the total cost over three years generally favours it once a hub passes a handful of producers.

Can Shopify or WooCommerce work for a farmers market with multiple producers?

They work as a shop window and break as an operations system. Multi-vendor plugins can split a basket and calculate a commission, but they do not handle producer-declared availability per delivery cycle, pick-and-pack splits, route assignment, crate deposits or a settlement run that survives an audit. Most co-ops using them end up running spreadsheets alongside, which reintroduces the errors the platform was meant to remove.

What is vertical SaaS in simple terms?

Vertical SaaS is software built for one industry rather than for every industry. Instead of offering generic building blocks you configure, it ships with the workflows, terminology and rules of a specific sector already built in. The trade-off is less flexibility across use cases in return for far less setup work and defaults that already match how the industry operates.

At what size does a food co-op need dedicated software instead of spreadsheets?

The trigger is usually the number of producers and delivery points rather than revenue. Spreadsheets cope while one person can hold the whole cycle in their head, typically under about ten producers with a single weekly drop. Once producers change their own availability, orders split across many pick lists and payouts need a defensible audit trail, coordination time grows faster than sales and the spreadsheet becomes the bottleneck.

Should a food hub build its own custom software instead of buying a platform?

Building custom software makes sense only if your operating model is genuinely unusual and you can fund maintenance indefinitely, not just the initial build. Most hubs underestimate the ongoing cost of payments, GDPR handling, mobile apps for drivers and producers, and the constant small fixes an operation demands. Buying a vertical platform and requesting changes is normally faster and cheaper than owning a codebase.