Build vs Buy for a Food Hub: The Five-Year Cost of the Custom Platform You Nearly Commissioned

Why the build quote is the least useful number in the decision

A custom build quote covers version one only. It excludes hosting, security patching, dependency upgrades, GDPR obligations, payout logic changes, support for producers who cannot log in, and the rebuild you need when producer count triples. In most food hub cases the first-year build is a minority of the five-year cost.

The pattern is consistent. A co-op board sees a proposal for a producer app, a shopper storefront, an admin back office and a driver view. The number looks large but survivable, especially if a rural development grant or LEADER fund covers part of it. What the proposal rarely states is that the software is a living system with recurring obligations, not a website that sits still once launched. Payment provider APIs deprecate endpoints. Mobile operating systems drop support for older builds. A framework hits end of life and stops receiving security fixes. None of these are feature requests, so none of them appear in the original scope, and all of them still have to be paid for.

There is a second omission. The quote assumes the specification is right. In a food hub it never is on the first attempt, because the operational rules only become visible once real orders flow through. The commission split that seemed simple turns out to have three exceptions. The declaration model that looked like inventory turns out to need a different data shape entirely. Every one of those discoveries is a change request against a fixed-price contract.

The five-year cost lines nobody puts in the board paper

The recurring costs of owning custom food hub software fall into seven categories: hosting and infrastructure, security and dependency maintenance, regulatory and compliance work, payments and payout logic changes, feature parity as the operation grows, internal product and support capacity, and key-person risk. Only the first is easy to forecast.

Take them one at a time in the context of a hub with a few dozen producers and a weekly delivery cycle. Hosting is genuinely cheap at this scale, often the smallest line. Security is not: someone has to watch dependency advisories, apply patches, rotate credentials, and respond when a library used by your payment flow gets a critical CVE on a Friday. That is not a task you can schedule around harvest season. Regulatory work is continuous rather than one-off, because GDPR obligations include handling access and erasure requests, keeping a defensible retention policy for driver location trails and shopper purchase history, and maintaining a processor agreement chain that survives an audit.

Payout logic deserves its own line because it changes more often than anything else in a food hub. Commission tiers get renegotiated. A producer asks to absorb packaging deposits differently. VAT treatment on a mixed box changes. Each change touches settlement code, historical records and the reports producers use to check they were paid correctly. On bought software that is a configuration change or a support ticket. On custom software it is a developer sprint, a test cycle and a migration for open orders.

Hosting, backups, monitoring and error tracking: predictable, usually the smallest recurring line
Security patching and dependency upgrades: continuous, unglamorous, non-negotiable
Framework and mobile OS version bumps: a forced rebuild roughly every two to three years
GDPR operations: DSAR handling, retention enforcement, processor agreements, breach readiness
Payout and pricing logic changes: the most frequent functional change in a multi-producer operation
Support for non-technical users: producers and drivers ring a person, not a ticket queue
Feature parity: the things buyers assume exist because every other platform has them

The feature parity trap: what growth quietly adds to scope

Feature parity is the cost of everything a custom build did not need at ten producers but cannot function without at forty. Substitutions, partial fulfilment, pickup points, credit notes, batch traceability for a recall, VAT edge cases and a producer-facing sales report are not nice-to-haves. They arrive as operational emergencies.

The order of arrival is fairly predictable. First a producer under-delivers and the admin needs a way to adjust an order after picking without breaking the payout. Then a shopper wants a refund on one line of a twelve-line box, which touches the split, the commission and the VAT. Then a second delivery day appears and the routing assumptions break. Then an inspector asks which grower supplied a specific crate of lettuce and you discover the system records product, not batch. Then someone asks for a report proving local spend for a grant renewal.

On a bought vertical platform these arrive as features other hubs already forced into existence, so you inherit them. On a custom build every one is a scoping conversation, a quote and a wait. The gap is not just money. It is the weeks your administrator spends running a workaround in a spreadsheet, which is exactly the state the project was supposed to end.

When building actually is the right call

Building is defensible when your operating model is genuinely unlike other food hubs, when the software is itself the commercial product you sell, or when you already employ product and engineering staff who will still be there in five years. If none of those are true, custom builds tend to become maintenance liabilities rather than assets.

A useful test is to ask what happens to the system when the person who commissioned it leaves. If the answer involves finding the freelancer who wrote it, or a repository nobody currently has access to, you are not buying an asset. You are buying an obligation with a bus factor of one. Larger hubs and regional aggregators with paid technical staff can absorb that. Volunteer-led or lean co-ops usually cannot, and the failure is rarely dramatic. The platform just stops being updated, drifts out of compliance, and gets quietly worked around until people are back on spreadsheets with an expensive login page in front of them.

There is also a middle path worth naming. Buy the transactional core, the catalogue, ordering, picking, routing, settlement and roles, and build only the thin layer that is genuinely yours. A custom impact dashboard, a local integration with a regional payment method, a bespoke onboarding flow for a specific funding programme. That keeps the expensive, high-churn, compliance-bound code someone else's responsibility, and puts your money where it creates something no competitor has.

How to run the comparison honestly in an afternoon

Compare on five-year total cost of ownership, not first-year price, and include the internal hours on both sides. Build a simple table with build or licence cost, recurring technical cost, internal staff time, cost of delay, and risk exposure. Score both options against the same operational change list, not against a feature checklist.

The operational change list is the part most boards skip and the part that decides the outcome. Write down the ten changes you know are coming in the next three years: a new delivery day, a second pickup point, a commission renegotiation, a packaging deposit scheme, a producer sales report, batch traceability, a new payment method, an impact report for a funder, a second language, and one integration with an accounting system. Then, for each option, write what that change costs and how long it takes. Bought software answers most of them with configuration and a support ticket. Custom software answers most of them with a quote.

Also price the delay. If a build takes nine months before the first live order and a bought platform takes six weeks, the difference is not just calendar time. It is seven and a half months of admin hours, order errors and producer frustration that you continue to pay for while waiting. In a small hub running on thin margins, that gap alone can outweigh the licence fee difference across the whole comparison period.

List five-year cost lines for both options, including internal staff hours
Score both against ten operational changes you know are coming, not a feature list
Price the delay to first live order in admin hours and error cost
Identify who owns security patching, GDPR requests and payout logic in each scenario
Ask what happens to the system if one named person leaves

What a bought platform still asks of you

Buying removes the engineering burden, not the organisational one. You still own data governance decisions, producer onboarding, change management, process design and the discipline of keeping declared stock honest. Vendors who claim otherwise are selling a fantasy that fails at rollout, not at contract signature.

The honest framing is a division of labour. The vendor carries security patching, uptime, framework upgrades, payment integrations, regulatory feature work and the accumulated edge cases from other hubs. You carry the decisions only an operator can make: what commission structure your producers accepted, how long you keep a driver's location trail, what a producer may see about another producer, and how you get a grower who has never used an app posting availability every Tuesday.

That is also the honest case for vertical software over both generic tools and custom builds. Generic platforms fail because their data model assumes one merchant. Custom builds fail because a food hub cannot sustain a software maintenance function alongside a delivery operation. A platform built by people running a short food supply chain sits in between: the multi-producer data model is already right, and the recurring cost of keeping it right is spread across everyone using it. Plodie is built that way because we run Plodovi.hr on the same code.

Key Takeaways

The build quote covers version one only. Hosting, security patching, GDPR operations, payout logic changes and feature parity dominate the five-year cost.
Payout and pricing logic changes more often than anything else in a multi-producer hub. On bought software it is configuration; on custom software it is a sprint.
Feature parity arrives as operational emergencies: substitutions, partial refunds, batch traceability, second delivery days, funder reports.
Building is defensible if software is your product, your model is genuinely unusual, or you employ permanent technical staff. Otherwise the bus factor is one.
Compare five-year total cost of ownership against ten operational changes you know are coming, and price the delay to first live order.

This is the second half of the decision; for the first half, see why generic software fails short food supply chains, which covers why ERPs and single-merchant e-commerce platforms break at the data model.

Frequently Asked Questions

How much does it cost to build a custom food hub platform?

Build quotes vary widely by region and scope, but the more useful question is the five-year total. A realistic model includes the initial build, hosting and monitoring, ongoing security and dependency maintenance, a framework or mobile rebuild every two to three years, GDPR operations, and a budget for functional changes to payout and pricing logic. Treat the initial quote as a fraction of what ownership costs, not the whole figure.

Can we build a food hub platform with a grant and then run it ourselves?

Grants usually fund capital build, not recurring maintenance, which is where custom platforms tend to fail. Before accepting build funding, confirm who will patch security vulnerabilities, handle GDPR access requests and change settlement logic in year three when the grant is closed. If there is no named, funded owner for that work, the platform will drift out of support.

What about open source food hub software instead of building or buying?

Open source removes licence cost but not operational cost. You still need someone to host it, upgrade it, patch it, adapt payout logic to your commission structure and support producers who cannot log in. It is a sensible option for organisations with in-house technical capacity and a tolerance for self-service support, and a poor one for a lean co-op with no developer.

Is a hybrid approach possible, buying a core platform and building custom parts?

Yes, and it is often the best value. Buy the transactional core where compliance and change frequency are highest, meaning catalogue, ordering, picking, routing, roles and settlement. Build only the thin layer that is genuinely specific to your organisation, such as a bespoke impact dashboard or a regional integration. Check the vendor exposes an API or export path before committing.

How do we avoid vendor lock-in if we buy instead of build?

Ask three questions before signing: can you export producers, shoppers, orders, payouts and delivery records in a structured format at any time, who is the data controller under GDPR, and what happens to your data if the contract ends. A vendor that answers all three clearly gives you a realistic exit, which is the practical protection against lock-in.