# Plodie — full text > Plodie offers specialized software designed to enhance the operations and impact of Small Farmers' Service Cooperatives. Every page and every article on https://plodie.com, as Markdown. The index is at https://plodie.com/llms.txt. Published by Reducos Software j.d.o.o. — https://plodie.com/contact-us --- ## Why short food supply chains URL: https://plodie.com/the-why To live in a world that is truly sustainable and filled with hope for the future: we must ensure the sustainable production and distribution of our food. Food is our primary human necessity, yet it accounts for nearly 1/3 of global climate issues. From intensive monoculture farming and excessive pesticide use to the energy-heavy processes of warehousing and global transport, our current system is unsustainable. And it’s not just harming our planet — it’s harming our health. Food distributed through global supply chains is degrading in nutritional value, aroma, and taste. Localised food systems are a proven, viable, and sustainable alternative. When food travels the shortest distance, it needs fewer pesticides, preservatives, and a fraction of the energy for storage and transport. We are no longer confined to a limited list of commodities suitable for global logistics, allowing us to embrace biodiversity and organic farming practices. This is why we embarked on a mission to revolutionise the way short food supply chains operate. We strive to provide comprehensive solutions for kickstarting and scaling localized food systems. By leveraging the Software as a Service (SaaS) model, we make high-quality, specialized software affordable for small farmers and short food supply chains. Through operating our own short food supply chain, [Plodovi.hr](https://plodovi.hr/), we gain daily, hands-on insights into the challenges and needs of these systems. The combination empowers us to provide both technological and business expertise to support short food supply chains. This is how we play our part in creating a future we can all look forward to and proudly pass it over to the next generation. --- # Applications Four applications, one platform. Each is the detail of a single role in a short food supply chain. ## Administrator app URL: https://plodie.com/administrator-app Plodie Administrator app allows you to control orders, manage logistics, and oversee your food supply chain for maximum efficiency With fully automated accounting for market owner and producers, short food supply chain accounting has never been easier. ### What can you do with an Administrator app? - Full control over your short food supply chain. Keeps customers happy. Provides easy-to-use customization, automation, and enhanced sales functionality — making it simpler than ever to build long-lasting customer relationships. - With other three apps available to you with Plodie, Admin app makes it easy to expand your capabilities as soon as you’re ready. ### Short food supply options at a fingertip - Automated accounting - Inventory management - Pickup locations - Routing engine - Controlling producer rates - Delivery regions, days & prices Administrator can provide technical support to all users and can be permitted to execute actions in the name of any user regarding deliveries, user inquiries and information. **Interactive dashboard.** Order and deliveries management and sale channels tailor made for your business. **Smart accounting.** On key events automatically generates necessary paperwork for market owners and producers. As well as tracking and overview of incoming invoices. **Inventory management system.** Admin has full control over the warehouse feature keeping track of products in-house, as well as keeping track of indicative quantities of products for the future. ## Shopper app URL: https://plodie.com/shopper-app Shoppers order from multiple producers and receive a single package, with real-time delivery tracking and direct contact with producers. Shoppers have options to order from multiple producers, and to communicate with them effortlessly. ### What can a user do with a Shopper app? - Order from multiple producers and expect products in a single package for delivery or pickup. - Order fresh local products that are harvested and delivered from multiple producers in the same day. Easy to use and intuitive app makes user experience pleasant and easy as never before. **Direct contact with admin and producer.** If there’s any issue with a product, delivery or else, the shopper can always reach out to admins or specific producers. **Real-time delivery visualization.** Track&trace: Real-time visualization of driver position with estimated time of arrival; push-notifications, even out of app. **Automatization of all orders.** Users can add additional products to existing orders and make special requests to producers. Orders are instantly visible to all relevant producers. ## Producer app URL: https://plodie.com/producer-app The Producer app gives growers full control over their profile, offering, orders and revenue statistics, with automated accounting built in. Increased user autonomy by providing tools to monitor their business performance as well as integrated CRM. ### What can you do with a Producer app? - Full control over producer profile and product offering. - Overview of upcoming and past orders and revenue statistics. - Automated accounting. A tailor made app for producers within the chain. The complete solution for producer operations in SFSC’s. **Direct contact with admins and shoppers.** Order notes from admins and shoppers; Overview and answering reviews and public questions. **SFSC specific functionalities.** Product order deadlines, available intervals, preorders, editing orders in case of unpredictable circumstances and date specific available quantities. **Automatization of all orders.** Shoppers can add additional products on existing orders before the deadline and make special requests to producers. ## Delivery app URL: https://plodie.com/delivery-app The Delivery app keeps a minimal carbon footprint with an advanced routing engine, live tracking and on-the-spot order changes. Minimal carbon footprint (minimal kilometers, time in transport, and food waste) ### Customized dashboard and advanced routing engine - In order to be efficient and timely, we use an advanced routing engine which calculates routes based on the number of orders, weight of products and locations. - The calculations are based on delivery vehicles and their capacity with real-time tracking on the dashboard. **Changeable payments on the spot.** Drivers can change payment methods, edit orders, postpone deliveries and send push notifications to other users. **Carbon efficient deliveries.** In order to have minimal carbon footprint, deliveries and trips to producers are efficiently calculated with our algorithm. **Real-time overview of operations.** Delivery users also have an option to leave notes to admin for producers and admin users. --- # Articles ## One Codebase, Eleven Co-ops: Multi-Tenant Architecture for Short Food Supply Chains URL: https://plodie.com/posts/one-codebase-eleven-co-ops-multi-tenant-architecture-for-short-food-supply-chain Published: 2026-09-21 · Category: Engineering · By: Ivan Lauc How to run many independent food co-ops as tenants on one platform: what belongs in shared code, what must be tenant configuration, where data isolation between rival co-ops matters, and where shared infrastructure stops working. ### Why a food co-op is a harder tenant than a typical SaaS customer A food co-op is a harder tenant because it is not a department inside a company, it is an independent legal entity with its own members, its own commission vote, its own delivery geography and its own producers. Two tenants on the same platform can be commercial rivals selling overlapping catalogues in overlapping postcodes. Most multi-tenant SaaS writing assumes tenants are interchangeable: same workflow, different logo, different row of data. That holds for a CRM. It does not hold here. One co-op charges a flat 15% commission on every line; another charges 8% plus a fixed weekly stall fee; a third takes nothing from producers and charges shoppers a basket fee instead. One runs a Tuesday cut-off with Thursday delivery; another runs standing boxes with no cut-off at all. One requires the market committee to approve every new producer; another lets an administrator add a grower in ninety seconds. None of those are feature requests in the usual sense. They are governance decisions made by member votes, and they change. A tenant that voted for flat commission in March can vote for tiered commission in November, and the platform has to absorb that without a code deployment and without touching the other ten tenants. That constraint, more than data volume or traffic, is what shapes the architecture. ### The line between shared code and tenant configuration The rule that holds up in practice: anything a co-op could vote to change belongs in tenant configuration, and anything that describes how food physically moves belongs in shared code. Commission rates, cut-off times, delivery zones and approval rules are configuration. Order lines, batch traceability, pick-and-pack splits and payout arithmetic are shared. That split works because the physical reality of a short food supply chain is genuinely identical across tenants. A crate still leaves a farm, still gets consolidated at a hub, still gets split across routes, still needs a batch reference if an inspector asks. Nobody votes on that. What co-ops vote on is money, membership and timing, and those map cleanly onto configurable values rather than branching logic. The failure mode to avoid is the tenant conditional: an if-statement somewhere in the settlement run that checks which co-op this is. Once one exists, more appear, and within a year the codebase has eleven behaviours nobody can test together. The discipline is to convert every such request into a named, documented setting with a sensible default. When a co-op asks for something that cannot be expressed as a value, that is a signal the underlying model is wrong, not that the tenant is unusual. - Tenant configuration: commission model and rate, payout schedule, cut-off and delivery day, delivery zones and fees, producer onboarding approval flow, refund and substitution policy, VAT handling, packaging deposit rules, branding and domain - Shared code: order and order line model, stock declaration mechanics, pick-and-pack split, route assignment, batch traceability chain, settlement arithmetic and rounding, role permissions, audit logging - Shared but tenant-scoped data: producers, shoppers, catalogue, orders, routes, payouts, reports ### Data isolation when two tenants are rivals in the same county Isolation between independent co-ops has to be enforced at the query layer, not the interface layer. Every query that touches tenant data carries a tenant scope by default, so a missing filter fails closed and returns nothing rather than leaking a neighbouring co-op's producer roster. Hiding a rival's data in the UI while it sits in shared API responses is not isolation. The commercially sensitive material in a short food supply chain is more specific than people expect. It is not just customer lists. It is which producers a co-op has signed, what commission they agreed to, which postcodes are profitable enough to deliver to, and what the weekly sell-through on a given product looks like. A competing co-op two valleys over would find all of that extremely useful, and some producers sell through more than one co-op, which means the same person exists as a producer record in two tenants with two different price lists. Those records must never reconcile across the boundary. Practical consequences follow. Search indexes are per-tenant or tenant-filtered at query time. Exports are generated inside a tenant scope and never from a cross-tenant admin view. Background jobs, which are the classic leak point because they run without a user session, carry an explicit tenant context rather than inheriting whatever was last set. And aggregate analytics used to improve the product are derived from anonymised, non-identifying counts, because the moment a benchmark is fine-grained enough to identify one co-op's performance, it stops being a product feature and becomes a disclosure. ### Controller and processor boundaries across independent tenants Under GDPR, each co-op is the data controller for its own shoppers, producers and drivers, and the platform is the processor acting on its instructions. That relationship is per tenant, so eleven co-ops means eleven separate controller relationships, eleven processing agreements and eleven independent sets of retention and deletion decisions. This is where multi-tenancy stops being an engineering convenience and becomes a legal structure. A subject access request arriving at Co-op A cannot be answered with data from Co-op B, even if the same shopper buys from both. A deletion request is executed inside one tenant only. If a producer sells through two co-ops, they have two controllers, and each one answers separately for the sales history it holds. Retention periods can legitimately differ: one tenant may keep driver location trails for 30 days, another for 7, because their members decided differently. It also means the platform cannot unilaterally repurpose tenant data. Improving a forecasting model with one co-op's order history is processing on that controller's behalf unless there is a lawful basis and an agreement that covers it. The clean position is that models trained on tenant data either stay inside the tenant or are built from data that has been aggregated past the point of identifiability, with the tenant told which applies. ### Where shared infrastructure stops working Shared infrastructure stops working at four predictable points: legal residency requirements, per-tenant scale that starves the others, customisation that cannot be expressed as configuration, and contractual demands for isolated backups or independent uptime guarantees. Each one is a reason to move a tenant onto dedicated resources, not a reason to fork the codebase. Residency is the most common. A co-op operating under a public grant or a county partnership may be required to keep personal data in a specific jurisdiction, which means a separate database or a separate deployment in that region. Scale is the second: a tenant running a Saturday market with several thousand simultaneous baskets while another tenant does thirty orders a week creates a genuine noisy-neighbour problem, and the fix is isolating the heavy tenant's database and job queues rather than over-provisioning for everyone. The third, deep customisation, deserves resistance before capitulation. Most requests that appear to need a fork are governance decisions in disguise and can become settings. But some are real: a tenant that needs an integration with a specific municipal invoicing system, or a payout model that is genuinely different in kind rather than in value. The honest answer there is a per-tenant extension point with a clear contract against the shared core, and a frank conversation about who pays to maintain it. The fourth is contractual. If a tenant wants its own backup schedule, its own restore testing and its own uptime commitment, that is a hosting tier, priced accordingly, and it should be sold as one rather than absorbed quietly. - Residency: personal data must stay in a named jurisdiction, so the tenant gets its own database or regional deployment - Scale: one tenant's peak load degrades others, so isolate its database, cache and job queues - Customisation: the requirement cannot be expressed as a configuration value, so it needs a documented extension point and a maintenance owner - Contract: dedicated backups, restore testing or an independent SLA, which is a hosting tier with a price, not a favour ### Running your own co-op as a tenant on your own platform The most useful architectural test is being a tenant on your own system. Plodovi.hr runs on Plodie as one tenant among others, with no privileged code path, no special-case branch and the same configuration surface every other co-op gets. If something cannot be configured, we feel it on a Thursday delivery like everyone else. This changes which shortcuts survive. A tenant conditional written for convenience becomes visible the moment it makes our own settlement run behave differently from a customer's. A missing setting becomes obvious when a commission change requires a developer instead of an administrator. And it keeps the isolation honest, because our own producer roster and sell-through numbers are exactly the kind of data another tenant should never be able to reach, and we have the same interest in that boundary holding as they do. It also constrains the roadmap in a healthy way. Features that only make sense for one co-op's particular habits get filtered out early, because building them means either polluting the shared core or admitting they belong in configuration. What is left is the part that is genuinely common to short food supply chains: declaration-based stock, multi-producer splits, route-bound delivery and settlement that has to reconcile to the cent, wrapped in enough configurability that eleven independent co-ops can each run the operation their members actually voted for. ### Key Takeaways - Treat anything a co-op could vote to change (commission, cut-off, zones, approval rules) as tenant configuration, and anything describing how food physically moves as shared code. - Enforce tenant isolation at the query layer so a missing filter fails closed, and give background jobs an explicit tenant context rather than an inherited one. - Each co-op is its own GDPR controller, so eleven tenants means eleven processing agreements, eleven retention policies and subject requests answered strictly inside one tenant. - Shared infrastructure stops working at data residency, per-tenant scale, customisation that cannot be a setting, and contractual backup or uptime demands. Each is a hosting or extension decision, not a codebase fork. - Running your own co-op as an ordinary tenant on the same codebase exposes special-case branches and missing settings faster than any internal review. For the operator's side of that last point, see [how Plodovi.hr drives our innovation](https://plodie.com/posts/building-better-SFSCs-through-experience-collaboration-and-technology), the co-op we run as a live tenant on the same platform our customers use. ### Frequently Asked Questions #### Should each food co-op get its own database or share one? Start with a shared database and strict tenant scoping on every query, because eleven separate databases multiply migration, backup and monitoring work without improving safety if the query layer is disciplined. Move a tenant to its own database when there is a concrete trigger: a data residency requirement, load that degrades other tenants, or a contractual demand for isolated backups and restore testing. #### How do you handle a producer who sells through two different co-ops on the same platform? They exist as two separate producer records, one inside each tenant, with independent price lists, commission terms and sales history. The records must not be linked or reconciled across the tenant boundary, because each co-op is a separate data controller for the relationship it holds. In practice the producer logs into each co-op's producer app separately and declares stock for each. #### What is the difference between multi-tenant and white-label for food hub software? White-label usually means branding: your logo, your domain, someone else's fixed workflow. Multi-tenant architecture done properly for co-ops goes further, letting each tenant configure commission model, cut-off times, delivery zones, approval rules and payout schedules against the same shared code. Branding is the easy part. Governance configurability is the part that decides whether a co-op can actually run its own rules. #### Can a platform use data from all its co-op tenants to build better forecasting or pricing models? Only with a lawful basis and an agreement that covers it, because each co-op is the controller of its own data and the platform is a processor acting on instructions. The clean approaches are models trained and used strictly inside a single tenant, or models built from data aggregated past the point where any individual co-op, producer or shopper is identifiable. Tenants should be told explicitly which applies. #### How do you roll out a change when eleven co-ops have different rules? Ship the change behind a configuration default that preserves existing behaviour, so no tenant sees a difference until an administrator opts in. Test against the full matrix of tenant settings rather than a single reference configuration, since the risk lives in combinations, such as a tiered commission tenant with a packaging deposit and a basket fee. Announce changes per tenant in their own operational language, not as a generic release note. ### Sources - [architect.salesforce.com](https://architect.salesforce.com/docs/architect/fundamentals/guide/platform-multitenant-architecture.html) - [scitepress.org](https://www.scitepress.org/papers/2012/39158/39158.pdf) - [sailpoint.com](https://www.sailpoint.com/blog/multi-tenancy-security-scale-innovation) - [ibm.com](https://www.ibm.com/think/topics/multi-tenant) - [rafay.co](https://rafay.co/ai-and-cloud-native-blog/what-is-multi-tenancy) --- ## The Integration Map of a Short Food Supply Chain: Which Connectors Pay Off, and Which Are Not Worth Building URL: https://plodie.com/posts/building-an-interconnected-local-food-system-the-api-and-integration-strategy-be Published: 2026-09-20 · Category: Product · By: Ivan Lauc A practical integration strategy for short food supply chain software: which systems a food hub actually needs to connect to, what an open API should expose, and which connectors cost more than they return. ### Why a Food Hub Needs an Integration Strategy, Not an Integration List A food hub needs an integration strategy because every connector it builds becomes a permanent maintenance obligation attached to someone else's roadmap. The useful question is not "can we connect to X" but "which record crosses the boundary, how often, in which direction, and what breaks when the other side changes". Vertical SaaS commentary is broadly right that open APIs are becoming table stakes. It is also written for categories where the counterparties are other software companies with versioned APIs and status pages. A short food supply chain touches a very different set of counterparties: a farm management app one grower uses, a certification body that publishes PDFs, a county agriculture department that wants a quarterly spreadsheet, a food bank that runs on a donated CRM, a logistics partner whose API is a single POST endpoint and an email address for support. So the strategy has to start by sorting counterparties by what they can actually sustain. Some can hold a live two-way integration. Some can only receive a file. Some are better served by a human copying nine numbers once a quarter. Treating all three as engineering problems is the fastest way to build connectors nobody uses. ### The Four Integration Tiers: Live API, Scheduled Export, Manual Handoff, and Don't Sort every potential integration into one of four tiers based on frequency of exchange and the counterparty's technical capacity. Live API for things that must be correct within minutes, scheduled export for anything reconciled weekly or monthly, manual handoff for low-frequency reporting, and a deliberate "don't build it" tier for everything else. The tier decides the engineering budget. A live API connector needs error handling, retries, idempotency, a sandbox, monitoring and someone on call when the counterparty deploys. A scheduled export needs a stable file format and a place to put it. A manual handoff needs a report screen with a copy button. Most integration regret comes from building tier one for a tier three relationship. The test for tier four is simple: multiply the number of times per year the data moves by the minutes it takes a human to move it. If that total is under a few hours annually, no connector will ever repay its maintenance cost, let alone the debugging sessions after the other side changes a field name. - Tier 1, live API: payments, card authorisation and refunds, courier label generation and tracking, anything a shopper sees in real time. - Tier 2, scheduled export or import: accounting ledgers, producer payout files, bank reconciliation, catalogue feeds to a partner marketplace, county reporting extracts. - Tier 3, manual handoff with a good report screen: grant reporting, certification renewals, food bank donation summaries, annual impact and food miles figures. - Tier 4, do not build: bespoke connectors to a single grower's farm management app, one-off ERP links for one restaurant customer, anything requiring you to mirror another system's stock model. ### Farm Management Software: The Integration Everyone Asks For and Few Can Use Farm management software integration sounds obvious and usually fails, because farm systems model growing (fields, plantings, inputs, harvest logs) while a hub models sellable availability for one delivery week. The two data models rarely line up, and in a 38-producer hub each grower uses a different tool, or none. The mismatch is specific. A farm record says a bed of lettuce was planted on a date and harvested in a quantity. A hub needs to know how many units a grower commits to delivering to a named pickup point on Thursday, at an agreed price, with packaging. Harvest volume is not a commitment, and crops harvested are not always crops offered. Pushing harvest logs into a catalogue produces availability numbers nobody stands behind, which is worse than an empty catalogue. The version that does work is narrow and grower-initiated: an import that pre-fills a declaration screen from a harvest log, which the grower then edits and confirms. The human confirmation stays. That also keeps the integration cheap, because it is a file or a read-only fetch rather than a synchronised state machine between two systems that disagree about what a kilogram of kale is. ### Certification, Food Banks and County Programmes: Reporting Boundaries, Not Data Pipes Certification bodies, food banks and county agricultural initiatives are almost always reporting boundaries rather than data pipes. They need periodic, auditable summaries in a fixed shape, not continuous access to the hub's transaction stream. The right build is a report generator with a stable definition, not an API integration. For certification, the platform's job is to hold the field and surface it correctly: a producer's certificate type, issuing body, certificate number and expiry date, plus a flag that hides or labels products when the certificate lapses. Automatically verifying against a registry is attractive and rarely available in a usable machine-readable form. An expiry reminder and a document upload cover the operational need, and the inspector wants to see the certificate and the batch trail, not an API log. Food banks and county programmes both want the same class of numbers: volume, value, origin, category, sometimes household counts. Because the definitions differ per programme and change between funding rounds, hard-coding a connector to one programme's current schema ages badly. A parameterised export, date range in, defined columns out, survives a schema change with a configuration edit rather than a release. ### Payments and Logistics: Where a Real API Actually Earns Its Keep Payments and delivery are the two places a live API clearly earns its maintenance cost, because both fail visibly and immediately in front of a customer. A declined card, a missing refund or an untracked box generates a phone call within the hour, which is exactly the threshold that justifies tier one engineering. Payments in a multi-producer hub are harder than in single-merchant retail, because one basket splits across many growers, the co-op's commission, packaging deposits and a delivery fee. The integration decision is whether the payment provider settles to one account with downstream payout logic in the platform, or whether it splits at authorisation. Most small hubs are better off with one settlement account and platform-side payout runs, because it keeps refunds, partial deliveries and substitutions in a single place rather than spread across provider-side split rules that cannot express "the courgettes were short by 400 grams". Logistics is narrower than it looks. Most short chains run their own van on fixed routes, so there is no carrier to integrate with at all, only a driver app. Third-party couriers matter for the edge: a chilled parcel to a customer off-route, or a restaurant order outside the delivery day. Build the courier connector when that edge becomes routine, and keep it to three calls: create shipment, fetch label, fetch status. ### What the Platform's Own API Should Expose, and to Whom A short food supply chain platform's public API should expose the records other systems legitimately need, catalogue, orders, deliveries, producers and payouts, scoped strictly by role, with webhooks for state changes and no endpoint that lets one producer read another's sales. Read-heavy, narrow, and boring is the correct design. Scoping is the hard part, and it is a governance question before it is an engineering one. A producer's token should return only that producer's lines. A partner marketplace pulling a catalogue feed should see availability and price but not the shopper behind an order. A county dashboard should receive aggregates, never addresses. The same access rules that govern the four apps must govern the API, or the API quietly becomes the hole in an otherwise careful data governance model. Webhooks matter more than polling for the events that trigger work elsewhere: order placed, order cut off, delivery completed, payout run closed. Those four cover most of what an external system genuinely needs to react to. Everything else can be a paginated read. And for the many partners who will never write code, the same data should leave the building as a scheduled CSV, because a well-specified file is an integration too. ### Key Takeaways - Sort every integration into four tiers: live API, scheduled export, manual handoff, or deliberately not built, and budget engineering accordingly. - Farm management integrations usually fail because harvest logs are not delivery commitments. A grower-confirmed import beats an automatic sync. - Certification bodies, food banks and county programmes are reporting boundaries. Build a parameterised export, not a bespoke connector to one schema. - Payments and couriers justify real APIs because they fail visibly in front of a customer within the hour. - Your own API must inherit the platform's role-based access rules, or it becomes the hole in your data governance. For the tier-two case in full detail, see our [accounting export deep dive](https://plodie.com/posts/the-accounting-export-that-nobody-reconciles-wiring-a-food-hub-platform-into-qui), which walks through exactly which records cross into QuickBooks, Xero and Stripe, and where multi-producer splits break single-merchant accounting. ### Frequently Asked Questions #### Does a food hub platform need an open API at all? Most small food hubs do not need one on day one, but they do need their data to be exportable in a documented, stable format. An open API becomes worthwhile once a third party, a county dashboard, a partner marketplace or a larger buyer, has committed to consuming the data on a recurring schedule. Before that point, a scheduled CSV export delivers the same outcome at a fraction of the maintenance cost. #### How do you integrate a food hub with a restaurant's ordering or procurement system? Start with email or a dedicated wholesale ordering view rather than an EDI-style connector. Restaurant procurement systems vary enormously, and one restaurant's system is almost never worth a bespoke integration. If several restaurants in your area share the same platform, a single connector that imports their purchase orders into your order book can be justified, ideally normalised into the same order pipeline as web baskets and phone calls. #### Can a short food supply chain platform pull certification status automatically from an organic certifier? Rarely, because most certification bodies publish registries as searchable web pages or PDFs rather than machine-readable APIs. The practical approach is to store certificate type, number, issuing body and expiry date against each producer, require a document upload, and automate the reminder before expiry. Manual verification once a year is cheap compared with maintaining a scraper against a page that changes without notice. #### What is the difference between a webhook and a scheduled export for food hub data? A webhook pushes a message the moment something happens, which suits events another system must react to quickly, such as an order being placed or a delivery completed. A scheduled export bundles a period's records into a file at a fixed time, which suits reconciliation, accounting and reporting. Webhooks need retry handling and an always-on listener on the receiving side, so they only make sense when the receiver can support that. #### How many integrations should a new food hub plan for in year one? Realistically two or three: a payment provider, an accounting export, and possibly a bank reconciliation file. Everything else, including farm management tools, courier APIs and programme reporting, can be handled by report screens and manual handoff until the volume proves a connector is worth its ongoing maintenance. Integrations built ahead of demand tend to be the first things to break silently. ### Sources - [dash.harvard.edu](https://dash.harvard.edu/entities/publication/73120379-020a-6bd4-e053-0100007fdf3b) - [github.com](https://github.com/whatfoodbanksneed/food_bank_api) - [online.ucpress.edu](https://online.ucpress.edu/elementa/article/12/1/00063/200345/Integrating-land-and-food-policy-to-transform) - [stackwareauthority.org](https://stackwareauthority.org/the-rise-of-vertical-saas-solutions-across-industries/) - [payproglobal.com](https://payproglobal.com/answers/what-is-saas-ecosystem/) --- ## Dynamic Pricing for Perishables in a Short Food Supply Chain: When an Algorithm Beats a Fixed Price List URL: https://plodie.com/posts/dynamic-pricing-for-perishables-in-a-short-food-supply-chain-when-an-algorithm-b Published: 2026-09-18 · Category: AI · By: Ivan Lauc Where algorithmic pricing actually helps a multi-producer food hub, which markdown decisions to automate against declared stock and remaining shelf life, and the three governance rules that stop producers revolting when the platform moves their price. ### When does dynamic pricing actually beat a fixed price list? Dynamic pricing beats a fixed price list in exactly one situation: when the product has a hard expiry and the stock is already committed. If a crate of lettuce is picked, declared and sitting in the hub, its value falls to zero on a known date. A fixed price ignores that clock. A markdown rule does not. Everything else usually stays fixed. Storable goods like honey, flour, oil, jam and dried herbs have no decay clock, so moving their price only trains shoppers to wait for a discount. Pre-order models where the shopper buys on Monday and the producer harvests on Thursday also have nothing to optimise, because stock is created to match demand rather than sitting at risk. The classic e-commerce case for demand-based pricing, where you raise prices when interest spikes, is the weakest of all in local food: a co-op's shoppers joined partly on a fairness promise, and surge pricing on tomatoes breaks that promise faster than any feature can repair it. So the honest framing is not "should we do dynamic pricing" but "which of our lines have a decay clock and uncommitted stock". In a typical hub catalogue that is leafy greens, soft fruit, fresh herbs, unpasteurised dairy, bread and prepared items, plus anything returned from a failed delivery. That subset is where an algorithm pays for itself. On the rest, a fixed list is not laziness, it is the correct answer. - Good fit: picked-and-declared perishables with 1 to 5 days of shelf life, surplus after the order cut-off, undelivered boxes back in the chill room, gluts where one producer declared triple their usual volume. - Poor fit: shelf-stable pantry goods, made-to-order and pre-harvest items, anything priced by a certification or scheme with a floor, products where a single producer is the only supplier and knows it. - Never: raising a price above the producer's listed price because demand looks strong. ### What the model is actually predicting, and the four inputs it needs A perishable pricing model does not predict a price. It predicts the probability that a given quantity sells before its expiry at the current price, then solves for the smallest discount that pushes that probability above a threshold. The output is a markdown percentage and a timestamp, not a clever price point. That reframing matters because it makes the problem tractable on small data. A short food supply chain has hundreds of order lines a week, not millions, so you are not going to learn a smooth demand curve per SKU. What you can learn is much coarser and much more stable: how fast a product category typically clears in the final 24 hours before cut-off, how much a 15 percent versus a 30 percent markdown historically shifted units in that category, and which weeks are structurally slow. A gradient-boosted model on a few thousand rows can do this. So can a well-tuned set of rules, and on a young catalogue the rules usually win. Four inputs carry nearly all the signal. Declared stock tells you what is at risk, which is why declaration quality upstream sets the ceiling on pricing quality downstream. Remaining shelf life, expressed as hours to the producer's stated best-before rather than a generic category default, gives the urgency. A baseline sell-through rate for the product at list price gives you the counterfactual. And committed demand, meaning baskets already open plus standing subscription lines that will consume stock automatically, tells you how much of the risk is already resolved. Weather, local events and holiday calendars help at the margins, but they are a second-order refinement, not the foundation. - Declared stock at unit level, per producer, with the declaration timestamp. - Hours to expiry from a producer-stated best-before, not a category average. - Baseline sell-through for the product or its category at list price, by day of week. - Committed demand: open baskets, standing boxes, confirmed restaurant lines. ### The markdown ladder: a rules engine you can explain to a 60-year-old grower Start with a transparent markdown ladder, not a model. A ladder is a small table of time-to-expiry bands mapped to maximum discount percentages, applied only to stock still unsold at each band. It captures most of the available waste reduction, it is auditable line by line, and a producer can predict what will happen to their price before it happens. A workable ladder for a two-delivery-week hub looks like this. From declaration until 24 hours before cut-off, everything sits at list price, because early discounting just cannibalises full-price sales that were going to happen anyway. At 24 hours before cut-off, unsold units on perishable lines get a modest step, typically 10 to 15 percent, and appear in a clearly labelled section of the storefront. After cut-off, any surplus that has not been allocated to a box moves to a second step, often 25 to 30 percent, and becomes eligible for surplus bundles or add-on offers to shoppers already receiving a delivery on that route. Anything still unsold on the morning of delivery goes to a final tier: donation, staff purchase, or a processing partner who turns it into soup stock or juice, at a price the producer agreed to in advance. Only once that ladder has run for a full season do you have something worth modelling. At that point you have labelled outcomes, the discount that was applied and whether the unit sold, and you can start replacing fixed percentages with predicted ones. The model's job is narrow: for this category, this day, this quantity, is 12 percent enough, or does it need 22 percent? That is a far safer place to put machine learning than asking it to invent a price from scratch. ### The three rules that stop producers revolting when the platform moves their price Producers revolt over pricing for one reason: the platform changed their number without their consent, and they found out from a shopper. Three rules prevent it. Producers set a floor and opt in per product, discounts are funded by a stated and visible split, and every price change is logged with a reason the producer can read. Rule one is producer-set floors with per-product opt-in. Each producer declares a list price and a minimum acceptable price, and the algorithm may only move within that corridor. Opt-in is per product, not per account, because a grower will happily discount lettuce and refuse absolutely to discount their specialty cheese. Default everything to opt-out and let producers switch lines on as they see the results. It feels slow and it is the reason the feature survives. Rule two is a funding split agreed before launch. A discount has to be paid for by someone, and if the answer is always the producer, the feature reads as the co-op protecting its own margin at the grower's expense. The common arrangement is proportional: on a 20 percent markdown, the producer accepts a lower unit price and the co-op accepts a lower commission, in the same ratio as the original split. Whatever the ratio, it belongs in the producer agreement and on the payout statement, so the grower can see both the discount and the co-op's share of it. Rule three is a change log attached to the product: old price, new price, trigger, timestamp, units sold at each tier. Producers do not need to love the algorithm. They need to be able to check it, and to see on Friday that the 18 kilos of chard they would otherwise have composted sold at 24 percent off and returned more than zero. One practical addition: give producers a manual override with no penalty and no friction. A grower who can pull a product out of the markdown ladder in two taps, at any time, almost never needs to. A grower who has to email an administrator will instead tell the other producers that the platform is discounting their food behind their back. ### How to measure whether it worked, and the failure modes to watch Judge dynamic pricing on three numbers: unsold perishable units as a share of declared stock, average realised price per unit against list, and producer income per declared kilo. Waste falling while realised price stays flat is the win. Waste falling while income per kilo falls is the algorithm simply giving away food. Run it as a split test rather than a launch. Take two comparable perishable categories, put one on the markdown ladder and leave the other on the fixed list for six to eight delivery weeks, and compare all three metrics. Keep an eye on the interaction effects, because they are where the damage hides. The most common is discount anticipation: a cohort of shoppers learns that Thursday evening brings 15 percent off greens and shifts their whole basket there, so you lose full-price revenue you already had. You detect this by watching the share of perishable units sold at list price over time, and you fix it by making markdowns less predictable in timing and by never discounting a line that cleared fully the previous week. Two other failure modes deserve a named owner. Cross-producer undercutting happens when two growers list the same product and the ladder marks one down, making the other look expensive for reasons they did not cause; a per-producer opt-in plus a rule that the ladder never discounts a line while a competing line is at list price and has stock removes most of it. And declaration gaming, where a producer inflates declared stock hoping for early exposure, shows up as a widening gap between declared and delivered quantities, which is a data quality problem to fix upstream rather than a pricing problem to fix in the model. ### Where this sits in the platform, and what to build first Dynamic pricing is not a pricing module. It is a thin decision layer sitting on top of three things a short food supply chain platform already needs: accurate declared stock with a timestamp, a per-line shelf-life field, and a payout engine that can apply a discount to both the producer's unit price and the commission. If any of those three is missing, build them before writing a single line of pricing logic. The build order that works is unglamorous. First, store a best-before or shelf-life-in-days value on every perishable product, entered by the producer during declaration. Second, add price floors and per-product markdown opt-in to the producer app. Third, implement the fixed ladder with a change log and a clearly labelled surplus section on the storefront. Fourth, wire the discount through settlement so payout statements show list price, realised price and who absorbed the difference. Only fifth, after a season of labelled outcomes, replace the fixed percentages with predicted ones. Most hubs capture the majority of the available waste reduction by step three and never need step five. At Plodie we came to this the same way we came to declaration-based stock, by running Plodovi.hr with a real producer base and watching what happened when the numbers on the storefront stopped matching what a grower expected. The conclusion was not that algorithms are unwelcome in local food. It was that a price is a relationship in a short supply chain, not just a number in a field, and any automation touching it has to be legible to the person whose name is on the product. ### Key Takeaways - Dynamic pricing only pays off on perishables with a hard expiry and already-committed stock; storable and pre-order lines should stay on a fixed price list. - The model predicts probability of clearing before expiry, then solves for the smallest sufficient markdown. It needs declared stock, hours to expiry, baseline sell-through and committed demand. - Start with a transparent markdown ladder tied to time-to-cut-off, not a model. Most of the waste reduction is available from rules alone. - Three rules keep producers on board: producer-set floors with per-product opt-in, a stated and visible discount funding split, and a per-product price change log. - Measure waste, realised price against list, and income per declared kilo together. Waste falling while income per kilo falls means you are giving food away, not optimising. Pricing quality is capped by declaration quality, which is why any markdown logic should be built on top of the [declaration-based stock model](https://plodie.com/posts/the-tuesday-night-text-message-how-38-producers-declare-next-week-s-availability) rather than a running inventory the platform has to guess at. ### Frequently Asked Questions #### Is dynamic pricing legal for food, and do I have to tell shoppers the price changed? Changing your own list prices over time is generally lawful, but consumer pricing rules in most European jurisdictions require that the price shown is the price charged at checkout, that any advertised discount references a genuine prior price, and that unit pricing is displayed for goods sold by weight. Practically, label markdowns clearly as a surplus or short-shelf-life offer rather than as a limited-time promotion, and never change a price inside an open basket. Check national rules on price-indication and promotional-discount reference periods before launching. #### How much data do I need before machine learning beats a fixed markdown ladder? You need labelled outcomes, meaning records of discount applied and whether the unit sold before expiry, not just sales history. As a rough guide, a season of trading with a few thousand perishable order lines and at least a few hundred marked-down lines per category gives a model something to learn from. Below that, a fixed ladder tuned by an administrator will usually match or beat a model while being far easier to explain. #### Should a food hub ever raise prices when demand is high? Almost never for shopper-facing prices. Surge pricing directly contradicts the fairness positioning most short food supply chains rely on, and it damages trust with both shoppers and producers far more than the extra margin is worth. The legitimate version is producers revising their own list prices between seasons or weeks in response to input costs and scarcity, which is a producer decision rather than an algorithmic one. #### What do we do with perishables that still do not sell after the final markdown? Agree the end of the ladder in writing before you need it. The usual tiers are donation to a food bank or social kitchen, staff and producer purchase at cost, transfer to a processing partner who turns surplus into soup, juice, pickles or stock, and composting as the last resort. Each tier should have an agreed price, including zero, so the producer knows in advance what a final-tier outcome pays them and the co-op can report the volumes in its waste and impact figures. #### Does dynamic pricing work for restaurant and wholesale customers as well as households? It works differently. Chefs buy on availability and consistency more than on price, so a surplus alert with a volume price is more effective than a percentage markdown on the storefront. The practical pattern is a separate surplus notification to wholesale buyers before the household markdown tier opens, since one restaurant taking 15 kilos of chard resolves the risk in a single transaction while retail markdowns clear it a kilo at a time. ### Sources - [today.ucsd.edu](https://today.ucsd.edu/story/dynamic-pricing-could-cut-greenhouse-gas-emissions-from-landfills-far-more-than-organic-waste-bans) - [pubsonline.informs.org](https://pubsonline.informs.org/doi/10.1287/mksc.2020.0214) - [foodprint.org](https://foodprint.org/blog/food-waste-management/) - [waste360.com](https://www.waste360.com/food-waste/how-dynamic-pricing-tech-is-cutting-grocers-food-waste) - [eitfood.eu](https://www.eitfood.eu/deep-dives/start-up-wasteless-tackles-food-waste-at-supermarkets-with-dynamic-pricing-algorithm) --- ## What It Actually Costs to Open a Local Food Hub: A €26,400 Year-One Budget, Line by Line URL: https://plodie.com/posts/what-it-actually-costs-to-open-a-local-food-hub-the-26-400-year-one-budget-behin Published: 2026-09-14 · Category: Business · By: Ivan Lauc A pre-launch budget for a local food hub serving 38 producers: one-off capital items, the weekly recurring cost per delivery week, and the three costs first-year founders forget. ### The short answer: about €26,400 for year one, split into capital and weekly cost A small local food hub aggregating 38 producers and delivering once or twice a week can open for roughly €26,400 in year one: around €9,900 in one-off capital and setup, and around €16,500 in recurring costs spread across roughly 46 delivery weeks. That is a lean, second-hand, one-coordinator build. The number moves in both directions for obvious reasons. Renting a shared chilled space instead of fitting one out removes most of the capital line and adds to the weekly line. Buying a van instead of leasing does the opposite. Hiring a full-time coordinator in month one instead of month nine roughly doubles the total. The structure below matters more than the total, because the structure is what tells you which costs you can defer until volume arrives. Two framing rules before the line items. First, separate anything you pay once from anything you pay every week you open the doors, because only the second kind determines your break-even basket count. Second, price every capital item at its realistic used value, not its catalogue price. Food hubs that launch with new equipment usually launch with debt they cannot service on 60 boxes a week. ### One-off capital and setup: roughly €9,900 The capital stack for a lean hub is dominated by cold chain and crates. A second-hand walk-in chiller unit and a small insulated room fit-out, a first fleet of returnable crates, a scale and label printer, basic pack-bench shelving, business registration and food business registration, and initial website and brand work together land near €9,900 for a hub packing out of a rented industrial unit or a shared kitchen. The line that surprises founders is crates. A returnable crate system is cheap per unit and expensive per fleet, because you need roughly three times the crates you think: one set at the hub, one set on the road, one set sitting in customers' hallways waiting to come back. At 60 boxes a week with a two-week return lag, a 250-crate fleet is not overkill. Food business registration cost varies enormously by country and by whether you handle only pre-packed goods or repack anything. Repacking, weighing loose produce into consumer units, or handling chilled meat and dairy moves you into a higher inspection category, sometimes requiring hand-wash stations, separate storage and documented temperature logs. Check that classification before you sign a lease, because it decides whether your €400 fit-out is a €3,000 fit-out. - Second-hand chiller unit and insulated cold room fit-out: €3,200 to €4,500 - Returnable crate fleet, 250 units plus deposit float: €1,600 to €2,200 - Pack bench, shelving, trolleys, scales, label printer: €900 to €1,400 - Company formation, food business registration, HACCP documentation and initial training: €600 to €1,200 - Brand, logo, photography and initial site setup: €700 to €1,500 - Thermometers, temperature loggers, cleaning kit, first aid, signage: €300 to €500 ### The recurring stack: what a delivery week actually costs Recurring cost is best expressed per delivery week, not per month, because a hub that opens 46 weeks a year does not pay pick-and-pack labour in the six weeks it is closed. For a hub doing 60 to 80 boxes a week, the weekly stack is roughly €355: coordinator hours, transport, packaging consumables, cold storage rent, software, card fees and insurance amortised. Transport is the line with the widest spread, and the decision is not van versus no van, it is fixed versus variable. A leased refrigerated van at around €420 a month plus fuel and insurance costs roughly €140 per delivery week regardless of whether you deliver 40 boxes or 140. A per-route courier or a paid driver with their own vehicle costs perhaps €2.20 to €3.50 per drop, which is cheaper below roughly 55 drops a week and more expensive above it. Most hubs should start variable and switch when the route density justifies a lease. Payment processing looks trivial and is not, because a food hub runs gross merchandise value through its account but keeps only a commission. At a €38 average basket, 70 boxes a week and a 1.4% plus €0.25 card fee, you pay about €55 a week in processing on roughly €2,660 of turnover. Against a 15% commission of €399, that is nearly 14% of your gross margin going to the card network. It is a real line, and it is one of the reasons cash-on-collection pickup points survive. - Part-time coordinator, 12 hours a week at €11 to €14 gross plus employer costs: €155 to €200 - Transport: €140 (leased chilled van) or €155 to €245 (per-drop courier at 70 drops) - Packaging consumables, bags, liners, ice packs, labels, tape: €35 to €55 - Cold storage or unit rent, share of utilities: €60 to €110 - Software platform and payment gateway subscription: €25 to €55 - Card processing fees at 70 baskets of €38: €50 to €60 - Public liability and product liability insurance, amortised weekly: €12 to €20 ### The three costs first-year founders systematically forget Three costs are missing from almost every food hub budget we have seen: packaging and crate shrinkage, unsold stock in weeks one to three, and the unpaid admin hours before volume justifies a salary. Together they typically add €2,000 to €3,500 in year one, and they are the difference between a plan that survives month four and one that does not. Crate shrinkage is the easiest to quantify and the most consistently ignored. Crates get kept, cracked, left at a pickup point, used as garden storage. A realistic loss rate is 8 to 15% of the fleet per year unless you run a deposit. A €3 deposit per crate does not eliminate loss, it just moves the cost to the person who caused it, which is exactly why it works. Budget either the deposit float as working capital or the replacement cost as an expense, and be explicit about which. Unsold stock in the first three weeks is the price of learning demand. Producers declare, you commit, households order less than you hoped, and the surplus is perishable. Plan on writing off 15 to 25% of stock value in week one, dropping fast by week four as declarations get tuned to actual orders. Cap the exposure by starting with consignment or declaration-based sourcing rather than buying stock outright, and by opening with a narrower catalogue than feels exciting. The unpaid hours are the hardest. Before a hub reaches roughly 60 boxes a week, the coordinator role is real work that the operation cannot afford to pay for. Founders absorb 15 to 25 hours a week of order reconciliation, producer chasing, route building and customer messaging. Costing those hours at even €10 makes the true year-one figure closer to €35,000. Write the number down even if you never pay it, because it tells you how urgently you need volume. ### The volume thresholds where each cost line stops hurting Each cost line has a box-count threshold above which it becomes proportionally trivial. At a €38 average basket and 15% commission, a hub earns €5.70 gross margin per box. Weekly cost of €355 means break-even sits at about 62 boxes a week. Every line below has its own crossover point, and knowing them tells you what to defer. Software and insurance are the first to disappear into the noise. A €35 weekly platform cost is 11% of margin at 55 boxes and 3% at 210. Cold storage behaves the same way: a fixed rent that hurts at 40 boxes is irrelevant at 150, which is why sharing a chilled space with another business in year one and taking your own unit in year two is usually the right sequence. The coordinator line is different because it steps rather than scales. Twelve hours a week covers roughly 80 boxes with good software and roughly 45 without, because reconciliation and producer chasing are the hours that grow fastest with producer count. The step from part-time to full-time arrives somewhere between 130 and 170 boxes a week, and that step is the single most dangerous moment in a hub's second year: the salary doubles the week before the volume does. Most hubs bridge it with a second part-timer on pick days rather than one full-time hire. - Break-even at €38 basket, 15% commission, €355 weekly cost: roughly 62 boxes per week - Card fees stop mattering above roughly 90 boxes, or sooner if you offer bank transfer and pickup - Van lease beats per-drop courier above roughly 55 drops on a tight route - Own cold storage beats shared space above roughly 120 boxes per week - Part-time coordinator capacity: roughly 80 boxes per week on a platform, roughly 45 on spreadsheets ### Three budget shapes, and which one to pick There are three defensible ways to open: the pickup-only hub at roughly €12,000 year one, the delivered hub described above at roughly €26,400, and the grant-funded hub at €60,000-plus that buys new equipment and hires before volume. The first two survive on trading revenue. The third survives on the grant, and its risk is what happens in month 13. The pickup-only hub drops the van, most of the cold chain and most of the packaging. Producers deliver to one weekly collection point, households collect in a two-hour window, and the whole operation runs out of a borrowed hall. It is the cheapest way to prove demand and the fastest way to discover whether your catalogue matches what people actually buy. Many hubs that eventually run vans should have started here. If you are writing a grant application, build the budget in this shape anyway, capital separate from weekly recurring, with a stated break-even box count. Funders respond better to a budget that shows how the operation stands up when the grant ends than to one that spends the full award. It also gives you the reporting structure you will need eighteen months later when you have to evidence what the money did. ### Key Takeaways - A lean 38-producer food hub opens for roughly €26,400 in year one: about €9,900 one-off capital and about €16,500 recurring across 46 delivery weeks. - Split the budget into one-off capital and cost per delivery week. Only the weekly figure determines your break-even box count, which sits near 62 boxes at a €38 basket and 15% commission. - Budget three times as many crates as you think you need, and either a deposit float or an 8 to 15% annual shrinkage rate. - The three forgotten costs are crate and packaging shrinkage, 15 to 25% stock write-off in weeks one to three, and 15 to 25 unpaid founder admin hours per week before volume justifies a salary. - Start transport variable (per-drop courier) and switch to a van lease above roughly 55 drops; share cold storage until roughly 120 boxes a week. Once the hub is trading and the coordinator hours become the binding constraint, the follow-on numbers are in our [year-one ROI model for leaving spreadsheets behind](https://plodie.com/posts/what-a-food-co-op-actually-saves-in-year-one-a-line-by-line-roi-model-for-switch), which prices the admin hours, order errors and delivery cost per box that this pre-launch budget only estimates. ### Frequently Asked Questions #### How many producers do you need to start a food hub? Fewer than most founders assume. A viable weekly box needs roughly 12 to 18 active producers to cover vegetables, fruit, eggs, dairy, bread and a few pantry items, with seasonal gaps filled by two or three of them. Growing to 38 producers adds catalogue depth and resilience, but it also multiplies reconciliation and payout work, so add producers only as fast as your admin capacity allows. #### Is it cheaper to rent a cold room or buy a chiller unit? Renting shared chilled space is cheaper below roughly 120 boxes a week because it converts a €3,000 to €4,500 capital item into a weekly rent you can stop paying. Buying a second-hand chiller and fitting out a small insulated room wins above that volume, and also wins earlier if you handle chilled meat or dairy and need dedicated, documented temperature control. #### Can a local food hub get grant funding for startup costs? Yes, and capital items are usually the easiest to fund. Rural development programmes, LEADER-type local action groups, regional agricultural agencies and municipal economic development funds commonly cover cold chain equipment, vehicles and digital tools. Operating costs such as salaries are harder to fund and often capped or time-limited, which is why your budget should show the hub reaching break-even on trading revenue without the grant. #### What commission do food hubs charge producers? Most short food supply chain hubs charge producers between 10% and 25% of the sale price, with 15% to 20% being the common band for hubs that handle aggregation, packing and delivery. Pickup-only hubs with minimal handling sit lower, around 10% to 12%. The commission has to cover the entire weekly cost stack, so run the arithmetic against your projected box count before promising a rate. #### How long does a food hub take to break even? Plan for 9 to 18 months to reach a sustainable weekly box count, assuming steady customer acquisition and a catalogue that matches local demand. The first three months are typically spent tuning producer declarations against actual orders and cutting write-offs. Hubs that launch with fixed costs sized for their year-two ambitions tend to run out of cash before they reach that volume. ### Sources - [rd.usda.gov](https://www.rd.usda.gov/sites/default/files/publications/SR77_FoodHubs_Vol3.pdf) - [ooooby.com](https://www.ooooby.com/news/food-hub-startup-guide) - [localline.co](https://www.localline.co/blog/how-to-create-a-food-hub-business-plan) - [foodsystemsjournal.org](https://foodsystemsjournal.org/index.php/fsj/article/download/430/408/810) - [durgesta.com](https://www.durgesta.com/en/articles/cold-storage-warehouses-requirements-and-costs) --- ## The Market Committee Vote That Decides Everything: 9 Governance Questions to Settle Before a Farmers Market Sells Online URL: https://plodie.com/posts/the-market-committee-vote-that-decides-everything-the-9-governance-decisions-a-f Published: 2026-09-13 · Category: Business · By: Ivan Lauc Taking a farmers market online stalls on governance, not software. Here are the nine decisions a market committee must vote on first, the options real markets chose, what each one forces in the platform, and wording for the motions. ### Why farmers market online launches stall on governance, not software Online farmers market launches stall because configuration questions get escalated to a committee that only meets monthly. Commission rate, refund liability, who owns the customer list: every one is a settings screen in the software and a governance decision in the constitution. The software waits for the vote. The pattern is consistent. A market signs up, an administrator starts configuring, and within the first afternoon hits a field that nobody is authorised to fill in. Does the market take 8% of an online order or charge a flat online stall fee? Is the refund the stallholder's cost or the market's? The administrator sends an email, the chair says it needs to go to the committee, and the committee meets in three weeks. Repeat that four times and a six-week launch becomes a five-month one. None of these are technology problems. They are questions about what the market actually is once it has a website: a landlord renting digital space, or a retailer that buys and resells. Markets have run for decades without answering that, because at a physical stall the answer is obvious. Cash goes from shopper to stallholder and the market collects rent. The moment one checkout collects money for forty stallholders, the ambiguity becomes a legal and accounting fact that somebody has to decide. ### Decisions 1 to 3: money, seller of record, and who holds the merchant account These three decide the market's legal identity online and must be settled together. Whether the market or the producer is seller of record for VAT, who holds the merchant account that receives card payments, and whether the market takes commission or a flat online fee are one interlocking question, not three independent ones. Two coherent models exist. In the agent model, each stallholder remains seller of record, the market acts as a disclosed agent, the customer's invoice names the producer, and the market charges a fee for the service. This keeps small producers under their own VAT registration thresholds and keeps the market's turnover small, but it needs software that can issue per-producer invoices from one basket and split one card payment across many payees. In the merchant model, the market buys from producers and sells to the shopper. Invoicing is simple and the market controls pricing and refunds, but the market's declared turnover now includes the full retail value of everything sold and the market carries the tax registration and the product liability that comes with being the retailer. The merchant account follows from that choice and cannot be decided separately. If the market is seller of record, it holds the account and settles producers by payout run. If producers are sellers of record, the platform needs split payments or a clearly documented client-account arrangement where the market holds money on behalf of producers. Markets that chose the agent model for tax reasons and then opened a single ordinary bank account in the market's own name created a mismatch that their accountant found at the first year end. Decide the tax position first, then open the account that matches it. - Motion 1 (seller of record): "That for online sales, the [market / individual stallholder] is the seller of record, with the market acting as disclosed agent where applicable, and that customer invoices are issued in the name of the [market / stallholder]." - Motion 2 (merchant account): "That online card payments are received into an account held by [the market / each stallholder via split payment], and that funds held on behalf of stallholders are recorded separately from market funds." - Motion 3 (market revenue): "That the market's revenue from online sales is [X% commission on the value of goods sold / a flat fee of €X per stallholder per month / a per-order fee of €X], reviewed after [6/12] months." ### Decisions 4 to 6: whether a stallholder can refuse an order, price parity, and non-participation These three decide what an online listing promises the shopper. Whether a stallholder may decline a confirmed online order, whether online price must match stall price, and what happens to stallholders who do not join determine whether the storefront is a guarantee or a request, and whether the market can advertise itself as the market at all. Refusal rights are the one most often skipped and the most expensive to skip. A grower who declared ten kilos of courgettes on Tuesday and lost half the crop on Wednesday will not fulfil ten kilos on Saturday, so the question is never whether refusals happen but what the customer experience is when they do. Markets generally land in one of three places: no refusal after cut-off, with the market sourcing a substitute from another stallholder; refusal permitted up to a stated hour with an automatic refund of that line; or full substitution rights where the picker swaps a comparable item. Each one is a different notification flow, a different refund rule and a different set of permissions in the producer app, which is why the answer has to exist before the configuration does. Price parity and non-participation shape the catalogue. If online price may exceed stall price to cover the market's cut, shoppers standing at the stall with their phone will notice, and someone has to be able to explain why. If parity is mandatory, the market's fee has to come out of the producer's margin, and the producers need to be told that in the same meeting. Non-participation is separate again: a market with 40 stalls and 12 online sellers is still a market, but the website copy, the search categories and the pickup messaging all have to be honest about it, and the committee should say explicitly whether joining is voluntary, opt-out by default, or a condition of the stall licence at the next renewal. - Motion 4 (refusal): "That a stallholder may decline an online order line up to [time] on [day], after which the order is binding; declined lines are [refunded automatically / substituted by the market with a comparable item at no additional cost to the customer]." - Motion 5 (price parity): "That online prices [must match / may exceed by no more than X% / are set freely by] the stallholder's market-day price, and that the market's fee is borne by the [stallholder / customer]." - Motion 6 (participation): "That online participation is [voluntary / opt-out / a condition of stall licence from DATE], and that non-participating stallholders [are / are not] listed on the website as market-day only." ### Decisions 7 to 9: who owns the customer, who answers the email, and who eats the shortfall These three decide who carries the operational load after launch. Customer ownership determines what a stallholder may see and do with shopper data, the support question decides whose inbox and phone number appear at checkout, and the shortfall rule decides who pays when goods ordered do not arrive. Customer ownership is a GDPR question dressed as a commercial one. If the market is controller of the shopper record, stallholders see order lines and pickup names but never the full contact list, and the market can run its own newsletter. If stallholders are joint controllers of their own customers, they can market directly, and the market has to write that into a data sharing agreement and a privacy notice the shopper actually sees. Markets that leave this unvoted usually discover it when one popular grower asks for a spreadsheet export of everyone who bought their cheese, and there is no policy to point to. Support and shortfall are the ones that decide whether the launch survives month three. Someone has to own the checkout email address, answer within a stated window, and have authority to issue a refund without convening anyone. That is a named role with stated hours, not a shared inbox. Shortfall is the same question on the money side: when a grower delivers six kilos against a ten kilo order, the customer is refunded four kilos of value, and the committee has to say whose money that is. The workable options are that the producer's payout is reduced by the undelivered value, that the market absorbs it from commission as a service cost, or that a tolerance band applies below which nobody is charged. Choose one, write it into the stallholder agreement, and the reconciliation run has an answer every week instead of an argument. - Motion 7 (customer ownership): "That the market is data controller for shopper accounts; stallholders receive only the order data necessary for fulfilment and may not export or use shopper contact details for their own marketing." - Motion 8 (customer support): "That [role] is responsible for all online customer contact, responding within [X] working hours, with authority to issue refunds up to €[X] without further approval." - Motion 9 (shortfall): "That where a stallholder delivers less than the ordered quantity, the customer is refunded in full for the shortfall and the [stallholder's payout is reduced accordingly / market absorbs the amount from its commission], subject to a tolerance of [X]% on weight-variable items." ### Running the vote: one agenda, one meeting, nine motions Put all nine motions on a single agenda and vote them in one sitting before any vendor demo is booked. Decisions 1 to 3 must be taken together because they are legally interdependent; decisions 4 to 9 can be voted individually. Record each outcome as configuration input, not as minutes prose. The practical sequence is to circulate a one-page paper a week ahead that states each question, the two or three real options and the downstream consequence of each, then hold a session with the accountant available for the tax question. Invite three or four stallholders who will be affected, because motions 4, 5 and 9 change how they get paid and a decision imposed without them in the room gets re-litigated at the first shortfall. Expect the refusal and shortfall motions to take the longest; they are where the market discovers what it actually believes about risk. Write the outcomes into a short online trading annexe to the stall licence rather than into the constitution. The annexe should carry a review date, typically six or twelve months, because at least two of the nine will turn out to be wrong. Commission rates get revised once real order values are visible, and refusal windows get tightened once stallholders see how a Friday decline lands on a Saturday picker. A decision with a review date is much easier to pass than one that feels permanent. - Circulate the nine questions with options and consequences one week before the meeting. - Have the accountant or bookkeeper present for motions 1 to 3. - Include affected stallholders for motions 4, 5, 6 and 9. - Vote 1 to 3 as a single resolution; vote the rest individually. - Record outcomes in a dated online trading annexe with a review date. - Only then book vendor demos, carrying the nine answers as your requirements list. ### What each answer becomes once you configure the software Every one of the nine answers maps to a specific setting, permission or document in a multi-producer platform. Bring the decisions to the vendor as requirements and configuration takes days. Bring them as open questions and the vendor picks defaults for you, which is how markets end up with a commission model their constitution does not support. The mapping is direct. Seller of record determines whose name prints on the invoice and whether one basket generates one invoice or several. Merchant account choice determines whether the platform runs split payments or a payout run. Commission versus flat fee determines the settlement calculation and what appears on a producer's remittance. Refusal rights determine whether the producer app has a decline button and what the cut-off enforcement does. Price parity determines whether producers hold one price list or two. Customer ownership determines what a producer sees on an order line: a name and a pickup slot, or a full contact record. Support ownership determines which address sends transactional email. Shortfall policy determines the reconciliation rule that runs every week without human intervention. Some platform defaults exist precisely because a market chose badly and had to unpick it. A default that hides shopper contact details from producers, a default that requires a declared cut-off before any storefront goes live, a default that reduces payout by undelivered value unless overridden: each of those is the safe position when governance is unclear, and each can be changed once the committee has actually voted. At Plodie we would rather configure a market than correct one, which is why the first conversation with an operator tends to be about these nine questions rather than about features. ### Key Takeaways - Online market launches slip on unresolved committee questions, not on software; each unanswered question is a configuration field nobody is authorised to fill in. - Seller of record, merchant account and market revenue model are legally interdependent and must be voted as one resolution, with the accountant in the room. - Refusal rights, price parity and participation rules decide what an online listing promises the shopper, and each maps to a different notification and refund flow. - Customer ownership, named support responsibility and a written shortfall rule decide whether the launch survives past month three. - Record all nine outcomes in a dated online trading annexe to the stall licence with a six or twelve month review, then book vendor demos with the answers as your requirements list. If your committee lands on split payments and per-producer invoicing, it is worth reading [why Shopify breaks at the second producer](https://plodie.com/posts/why-shopify-breaks-at-the-second-producer-what-happens-to-payouts-stock-and-pick), which covers the six points where a single-merchant storefront fails a multi-producer market. ### Frequently Asked Questions #### Does a farmers market need to register for VAT to sell online? It depends entirely on whether the market is seller of record. If the market buys from stallholders and resells, the full retail value counts toward the market's turnover and registration thresholds apply. If the market acts as a disclosed agent and each stallholder remains seller of record, only the market's commission or fee counts as its own turnover. Confirm the position with an accountant before choosing a payment setup, because the two models need different bank arrangements. #### How long does it take to launch an online farmers market once the decisions are made? With the governance settled, the limiting factors are catalogue building and producer onboarding rather than configuration. Expect a few weeks to photograph and list products, train stallholders to declare availability, and run a parallel pilot with a small group of shoppers before opening publicly. Markets that arrive with open governance questions typically add months because each unanswered question waits for the next committee meeting. #### What if only a few stallholders want to sell online? That is workable and common at the start. A market with 40 stalls and 10 online sellers can launch, provided the website is honest about which producers are available online and the pickup messaging does not imply the whole market is represented. Voluntary participation with a review date usually gets more sign-ups over time than making it a licence condition on day one, because reluctant stallholders get to watch the first cohort get paid. #### Should a farmers market charge commission or a flat monthly fee for online sales? Commission scales with volume and keeps the market's interest aligned with producer sales, but it makes small orders relatively expensive to process and it complicates price parity. A flat fee is predictable for stallholders and simple to invoice, but it can mean the market runs the storefront at a loss in the early low-volume months. Many markets start with a flat fee during the pilot period and switch to commission once order volume is visible, which is why the motion should carry a review date. #### Who is liable if a customer gets ill from something bought through the market's website? Liability tends to follow the seller of record. If the market is the retailer, it carries retailer obligations including product liability and recall duties; if the stallholder is seller of record with the market as agent, primary responsibility stays with the producer. Either way the market needs traceability records linking each order line to a producer and a batch, and its insurer should be told that the market now sells online. --- ## The Accounting Export Nobody Reconciles: Wiring a Food Hub Into QuickBooks, Xero, Stripe and a CRM URL: https://plodie.com/posts/the-accounting-export-that-nobody-reconciles-wiring-a-food-hub-platform-into-qui Published: 2026-09-12 · Category: Product · By: Ivan Lauc Which records actually cross the boundary between a food hub platform and QuickBooks, Xero, Stripe or a CRM, where multi-producer splits break single-merchant accounting, and which integrations are not worth building. ### Why the standard accounting export breaks at the second producer A food hub is not one merchant selling its own goods. It is a marketplace where one customer payment fans out to eleven producers, a commission line, a delivery charge, a packaging deposit and two or three VAT rates. Standard e-commerce accounting exports assume a single seller, so they collapse that fan-out into one sales figure and lose the payable side entirely. The practical symptom is familiar. The export lands in QuickBooks or Xero as a daily sales receipt, revenue looks enormous because it includes money the hub is only holding on behalf of growers, and the bookkeeper then manually creates purchase invoices for each producer from a separate payout report. That is the second data entry job. It is invisible in demos because demos use one producer and one VAT rate. The fix is not a better CSV. It is deciding, before any connector is built, what the hub is in accounting terms: an agent collecting on behalf of producers, or a principal buying and reselling. Those two models produce completely different ledgers from the same order, and getting it wrong means every export afterwards is reconciling to a number that was never going to match. ### Agent or principal: the one decision that determines every integration after it Under the agent model, the hub's revenue is only its commission and delivery fee. Producer money is a liability, not income. Under the principal model, the hub buys from producers and resells, so the full basket value is revenue and producer invoices are cost of goods sold. Pick one, write it down, then build exports to match. The agent model usually keeps the profit and loss statement honest for a co-op that never takes ownership of the goods. A basket of 380 euros of produce plus 42 euros of commission shows as 42 euros of revenue and 380 euros sitting in a producer payable account until settlement. It also means the hub's turnover figure stays small, which matters for VAT registration thresholds in some jurisdictions and can matter for grant reporting. The principal model is simpler to explain to a high-street accountant and is often forced on you anyway if the hub sets retail prices, absorbs unsold stock, or issues the customer a receipt in its own name for the whole basket. The cost is that your revenue line now includes money that was never yours to keep, and margin analysis requires a matching producer cost line for every single order. Whichever you choose, the platform must be able to emit both sides consistently, and your accountant should confirm the choice before go-live, not during the first VAT return. - Agent: revenue = commission + delivery + fees. Producer share = liability. Producer settlement = clearing the liability, not an expense. - Principal: revenue = full basket. Producer share = purchase invoice booked to cost of goods sold. - Mixed reality: some hubs are principal on their own-brand boxes and agent on marketplace lines. That is legitimate but needs two separate account mappings, not one toggle. ### Which records actually cross the boundary, line by line Six record types need to reach the accounting system, and only six: customer sales with VAT split by rate, producer settlements, commission and fee income, delivery and packaging charges, payment processor fees and payouts, and refunds or credits. Everything else, including order lines, stock declarations and route data, stays in the platform. The discipline is to send summaries, not transactions. A hub running 400 orders a week does not need 400 invoices in Xero. It needs one daily or weekly sales journal broken down by VAT rate and revenue account, one settlement run posted as producer bills, and one Stripe payout reconciled against a clearing account. That keeps the ledger small enough for a human to audit and keeps the API call volume inside free-tier limits. Refunds and deposits are where most exports quietly fail. A refunded punnet of strawberries has to reverse the customer sale, reverse the producer's share if the settlement has not run yet, or create a deduction on the next settlement if it has. A returned crate deposit is not revenue at all, it is a refundable liability that should sit in its own account and unwind when the crate comes back. If the export treats deposits as sales, the ledger slowly accumulates income that will never be earned. - Customer sales journal: gross by VAT rate, per settlement period, with a reference back to the platform batch ID. - Producer settlement: one bill per producer per run, with the platform's settlement number as the bill reference. - Commission and fees: hub income, booked separately from delivery and from packaging. - Payment processor: gross charges, processor fees as an expense, payouts against a bank clearing account. - Refunds and credits: credit note against the original batch, plus a settlement deduction if the producer was already paid. - Deposits: balance sheet liability, never revenue, unwound on crate return or forfeited after a stated period. ### Stripe, Stripe Connect and the money that is not yours Stripe reconciles cleanly only if you treat its payouts as bank transfers from a clearing account, never as revenue. Charge the customer, book the gross amount to a Stripe clearing account, book the processor fee as an expense, then match the bank deposit against the clearing balance. The difference between gross sales and bank deposit is fees and timing, nothing else. Stripe Connect is tempting because it can split a payment to multiple connected accounts automatically. For most food hubs it is the wrong tool, and the reason is timing rather than technology. Producer amounts are not final at checkout. A grower who declared 12 kilos of courgettes and delivered 9 changes the split after the money has already moved. Substitutions, short deliveries, quality rejections and weight-based items all settle after the pick and pack, so a split-at-checkout model forces you into reversals and negative balances on grower accounts. The pattern that holds up is: take one payment to the hub, settle producers on your own cycle from the platform's settlement run, and pay by bank transfer or batch payment file. Connect earns its place when producers need to be paid at checkout speed, when local rules push the money flow out of the hub's account for regulatory reasons, or when the hub genuinely never wants funds touching its balance. Otherwise the operational cost of reconciling hundreds of micro-transfers exceeds the benefit. If you do use Connect, model application fees, transfer reversals and negative balance handling before the first live weekend, not after. ### The CRM question: what a food hub actually needs from HubSpot or a mailing list Most food hubs need email segmentation and a wholesale pipeline, not a CRM. Shoppers are already fully described inside the platform by their order history, so pushing them into HubSpot or Pipedrive duplicates data that goes stale immediately. The genuinely useful CRM sync is narrow: restaurant and retail accounts, and marketing consent for newsletters. Wholesale is different from retail because it has a sales cycle. A restaurant is a lead before it is a customer, someone chases it, there are pricing conversations, credit terms and a named contact who can churn. That belongs in a CRM or a deal pipeline. Household shoppers do not have a sales cycle, they have a basket frequency, and the platform already knows it better than a CRM ever will. For marketing, sync a small consented segment to the email tool and keep it one-directional. Push email address, consent flag, order recency, basket frequency and pickup location. Do not push line-item purchase history into a third-party tool unless your privacy notice covers it and you have a reason beyond curiosity. Every field you copy out is a field you now have to delete twice when someone exercises a deletion request, and a field that can contradict the platform the moment a shopper changes their address. ### Which integrations are not worth building, and what to do instead Skip any integration where the volume is low, the data is ambiguous, or the failure mode is silent. That usually rules out real-time two-way accounting sync, inventory sync with producers' own systems, ERP connectors for a ten-person operation, and automated logistics APIs for a two-van route. A scheduled export plus a person who checks it beats a fragile live connector. Two-way sync deserves special suspicion. The moment an accountant can edit a producer bill in Xero and the platform can also edit it, you have two sources of truth and a conflict resolution problem nobody wants to own. Keep the platform authoritative for anything derived from orders and settlements, and let the accounting system be authoritative for everything downstream: journals, tax returns, bank reconciliation, payment runs. The test for building anything is simple. Estimate the manual minutes per week the integration removes, multiply by 50, and compare against the cost of building it and the cost of investigating it the three times a year it silently stops. A weekly settlement export that saves four hours of re-keying is worth automating. A live CRM sync that saves someone a copy and paste twice a month is not, and it will quietly desynchronise until someone emails the wrong list. - Worth it: scheduled sales journal and producer bill export to QuickBooks or Xero. - Worth it: payment processor payout reconciliation against a clearing account. - Worth it: one-directional consented email segment sync. - Usually not: real-time two-way accounting sync, producer-side stock sync, ERP connectors, carrier APIs for short local routes, automated bank payment initiation without a human approval step. ### Key Takeaways - Decide agent versus principal accounting before building any export. It determines whether producer money is revenue or a liability, and every downstream mapping depends on it. - Only six record types need to cross the boundary: sales by VAT rate, producer settlements, commission and fees, delivery and packaging, processor fees and payouts, and refunds or credits. - Send periodic summaries, not per-order invoices. One sales journal and one bill per producer per settlement run keeps the ledger auditable by a human. - Stripe payouts belong in a clearing account, never in revenue. Stripe Connect's split-at-checkout model fights the reality that producer amounts change after pick and pack. - Avoid two-way sync. Keep the platform authoritative for order-derived data and the accounting system authoritative for journals, tax and bank reconciliation. The settlement run these exports depend on is broken down line by line in our [anatomy of a producer payout](https://plodie.com/posts/the-anatomy-of-a-producer-payout-how-we-split-a-38-vegetable-box-between-11-grow), which walks through splitting a €38 vegetable box between 11 growers, commission, deposits and VAT. ### Frequently Asked Questions #### Can QuickBooks or Xero handle multi-producer payouts natively? Not as a marketplace. Both can record producer bills and clear them in a payment run, which is all you need, but neither can calculate the split from an order. The platform must produce the settlement, including commission, deposits, delivery share and VAT treatment, and then hand the finished producer bills to the accounting system as payables. #### How often should a food hub export to its accounting system? Match the export cycle to the settlement cycle, which for most hubs means weekly or fortnightly. A weekly sales journal plus a weekly batch of producer bills gives the bookkeeper a predictable rhythm and keeps the ledger small. Daily exports add noise without improving anything unless you are reconciling cash daily. #### Do producers need to issue their own invoices to the food hub? It depends on the model and local tax rules. Many co-ops use self-billing, where the hub generates the producer invoice from the settlement run and the producer agrees to it in writing in advance. That is far more reliable than waiting for 38 growers to send correctly numbered invoices, but self-billing arrangements usually need a signed agreement and correct VAT handling, so confirm the requirements with your accountant. #### What happens to the accounting export when a customer is refunded after producers have been paid? The customer sale is reversed with a credit note, and the producer's share becomes a deduction on their next settlement rather than a clawback. Your platform should carry that deduction forward automatically with a reference to the original order so the producer can see why their payout dropped. If the producer is not at fault, for example a delivery failure, the hub absorbs it and the deduction never reaches the grower. #### Is a CSV export good enough, or do I need a real API integration? For most food hubs under a few thousand orders a month, a well-structured CSV that maps cleanly to your chart of accounts is genuinely good enough and far easier to audit when something looks wrong. Move to an API connector when the re-keying is costing hours per week or when the bookkeeper is making transcription errors. The value is in correct mapping, not in the transport method. ### Sources - [developer.xero.com](https://developer.xero.com/documentation/api/accounting/creditnotes) - [docs.stripe.com](https://docs.stripe.com/connect/charges) - [soundpost.ai](https://soundpost.ai/blog/best-practices-for-accounting-integrations-strategy-and-control) - [ramp.com](https://ramp.com/blog/accounting-data-migration) - [quickbooks.intuit.com](https://quickbooks.intuit.com/r/bookkeeping/data-map/) --- ## The Grant Application a Co-op Can Actually Evidence: Mapping Platform Data to Proposal Sections and Post-Award Reports URL: https://plodie.com/posts/the-grant-application-a-co-op-can-actually-evidence-turning-platform-data-into-f Published: 2026-09-11 · Category: Business · By: Ivan Lauc Most food hub grant advice stops at where to apply. This is the operator's version: which transaction lines, producer payouts and delivery records map to each section of a funding proposal, and how the same data satisfies post-award reporting deadlines. ### Why most co-op grant applications fail on evidence, not ambition Most local food grant applications are rejected or downgraded because the baseline and targets are unverifiable, not because the idea is weak. Assessors look for numbers the applicant can show the source of. A co-op that cannot produce last year's producer count, local spend or delivery volume from records loses points on feasibility and monitoring. There is a pattern to the weak sections. The narrative is strong, the partnership letters are in place, and then the indicator table says something like "expected increase in producer income of 20%" with no stated baseline and no described method. An assessor cannot score that. Worse, the applicant cannot report against it eighteen months later, because the number was never derived from anything. The second failure comes after the award. Grants in rural development, regional operational programmes and food systems funds almost always require interim and final reports with the same indicators, plus financial breakdowns tied to eligible cost categories. Co-ops that assembled the application from estimates then spend weeks reverse-engineering figures from bank statements and email threads. The work is worse the second time, and any inconsistency between application and report invites questions. ### Which platform data maps to which section of the application Almost every section of a food systems grant application has a matching data source in an operating co-op: order lines for demand, producer records for supply base, payout runs for producer income, route logs for logistics, and delivery records for reach. The mapping is mechanical once you write it down. The mapping below is the version we use for Plodovi.hr, our own 38-producer co-op in Croatia, when preparing applications to county, national and EU-funded schemes. Wording of sections varies by funder, but the underlying questions repeat: who are you, what do you currently do, what will change, how will you know, and how will you prove the money was spent on that. Two practical rules make this hold together. First, state the extraction period explicitly for every figure, for example "1 January to 31 December, order lines with status delivered". Second, keep one definitions file that states what counts as an active producer, a local producer and a fulfilled order. If the definitions drift between application and final report, the numbers will not reconcile. - Applicant capacity and track record: producer count by status and county, years active, number of distinct fulfilled orders, number of active buying households and B2B accounts. - Needs analysis and baseline: 12 months of order lines by category, unmet demand signals such as out-of-stock declarations and unfulfilled basket items, average producer revenue per active producer. - Market and demand evidence: repeat purchase rate, basket composition, restaurant and institutional order volume, seasonality curve by month. - Project activities and workplan: current cut-off, pick-pack and route cycle as the as-is process, with the specific step the grant will change. - Indicator table and targets: baseline value, source query, extraction date, and the same query re-run as the target measurement method. - Sustainability and environmental sections: route distances per delivery, average kilometres from producer to consolidation point, packaging deposit returns, unsold and donated volume. - Social impact and inclusion: share of turnover paid to producers, number of producers below a given farm size, delivery coverage of rural settlements, food access initiatives by volume. - Budget justification: current admin hours and cost per order, current cost per delivery drop, both used to justify why the requested investment is proportionate. ### How to build the indicator table so post-award reporting is a re-run, not a rebuild Write every indicator as a saved query, not a sentence. Each row should carry a baseline value, the exact filter that produced it, the extraction date, and the person or role who owns the re-run. At report time you change the date range, re-run, and paste. That turns a two-week reporting scramble into an afternoon. The discipline that makes this work is resisting indicators you cannot compute. If a funder offers a menu of indicators, pick the ones your records already support. "Number of producers with increased annual sales through the co-op" is computable from payout history. "Increased consumer awareness of local food" is not, unless you commit to running a survey, in which case budget the survey as an activity with a cost line. Tie each indicator to the reporting calendar from day one. Most schemes want an interim report at the midpoint, a final report within a set window after project end, and in some cases annual ex-post reports for three to five years. If an indicator requires a full calendar year to measure and your final report is due in March, you need to know that before you sign the contract, not after. - Indicator name exactly as written in the grant contract, not a paraphrase. - Baseline value plus the filter that produced it (date range, order status, producer status). - Unit and direction of change, so 'increase' or 'share of total' is never ambiguous. - Measurement frequency and the reporting deadline each measurement feeds. - Owner and fallback owner, because staff and volunteers change during a three-year project. - Evidence artefact the assessor can request: exported CSV, payout run PDF, route log, signed delivery confirmation. ### Producer payout data is the strongest evidence most co-ops already hold Producer payout records answer the question funders care about most: how much money actually reached small producers, and did it grow. A settlement run that splits each order between producers, co-op commission, delivery cost and VAT gives a per-producer, per-period income figure that is far more defensible than a turnover total. This matters because "turnover increased" is a weak claim for a co-op. Turnover includes commission, delivery fees and packaging deposits. Funders assessing rural income support want the producer share. A payout ledger lets you report share of gross sales paid to producers, number of producers whose payouts grew year on year, median payout per active producer, and concentration, meaning how much of total payouts went to the top five producers. That last one is uncomfortable but valuable, because it shows honestly whether growth is broadening or concentrating. Payout data also carries you through financial reporting. Grant auditors work in eligible cost categories and want to trace claimed costs to invoices and payments. A co-op whose payouts, commissions and delivery costs are separated per order can answer "which part of this revenue was grant-supported activity" without unpicking a single bank line. For the mechanics of how a single box splits across growers, commission, packaging and VAT, the settlement structure matters more than the accounting software you export it to. ### The post-award reporting calendar and what it demands each time Post-award reporting usually comes in four types: financial claims against eligible cost categories, activity or progress narratives, indicator measurements, and publicity or visibility compliance. Each has a different data source, and the mistake is treating them as one document assembled at the end. Financial claims need procurement trails and payment evidence, which live in accounting, not the operations platform. Activity narratives need dated records of what happened: when onboarding sessions ran, how many producers attended, when the new route launched. Indicator measurements need the saved queries. Publicity compliance needs screenshots and dated links showing funder logos and acknowledgement on the storefront, newsletters and any signage. The practical structure that keeps this manageable is a monthly ten-minute habit rather than a quarterly panic. Once a month, export the indicator queries, drop them in a dated folder, and add a two-line note on activities completed. When the interim report is due, the evidence is already in chronological order, and any gap is visible while it can still be fixed. Also keep a change log: if a delivery route was dropped or a producer left mid-project, an assessor who spots the dip will ask, and a dated explanation written at the time is worth far more than a reconstruction. - Monthly: re-run indicator queries, save dated exports, note activities completed and anything that slipped. - Quarterly: reconcile payout totals against accounting, check publicity obligations are still visibly met. - Interim report: indicator measurements against baseline, narrative of activities, financial claim for the period, explanation of any variance over the funder's threshold. - Final report: full-period indicators, cumulative financial claim, evidence pack of exports and artefacts, statement of deviations from the approved workplan. - Ex-post years: the same indicator queries only, which is why they must stay runnable after the project team disperses. ### Where software genuinely helps, and where it cannot Software helps with the parts of a grant that are derived from operational records: baselines, indicator measurements, payout breakdowns, route distances, delivery coverage and repeat purchase behaviour. It cannot write your needs analysis, build your partnership, or judge whether a scheme fits your strategy. Those remain human work. The useful boundary is this. If a figure is a count, sum, share or distance over records you already create by operating, a platform should produce it on demand and reproducibly. If a figure requires interpretation, attribution or a counterfactual, for example "jobs created" or "emissions avoided compared with supermarket supply", software can supply the inputs but you must state the method and its limits in the application. Funders rarely penalise a stated method with stated limits. They penalise unsourced confidence. At Plodie we built the social impact, food miles and payout reporting because we needed them for our own co-op's applications and reports, not as a marketing feature. The test we use is whether an administrator can re-run a figure eighteen months later, get the same number for the same period, and point an assessor at the underlying order lines. If a report cannot survive that, it should not go in a proposal. ### Key Takeaways - Grant applications are scored on verifiable baselines and measurement methods, not on ambition, and the same numbers are required again in interim, final and ex-post reports. - Almost every application section has a data source in an operating co-op: order lines, producer records, payout runs, route logs and delivery confirmations. - Write each indicator as a saved query with its baseline, filter, extraction date and owner, so post-award reporting becomes a re-run instead of a rebuild. - Producer payout ledgers are stronger evidence than turnover, because funders want the producer share, not commission and delivery fees. - Only commit to indicators your records can compute, and state the method and limits for anything requiring attribution or a counterfactual. The derivation method behind most of these indicators is set out in [social impact report a co-op can actually defend](https://plodie.com/posts/the-social-impact-report-a-co-op-can-actually-defend-turning-transaction-data-in), which covers local spend, producer income and food access figures line by line. ### Frequently Asked Questions #### What grants can a small food co-op or food hub actually apply for? In the EU, the most common routes are rural development measures under the CAP strategic plans, LEADER local action group calls, regional operational programme calls for SMEs and cooperatives, and thematic food systems or circular economy funds. County and municipal budgets often fund smaller equipment and digitalisation items. Eligibility usually hinges on legal form, producer membership and whether the activity counts as processing, marketing or short supply chain development, so check the definitions section of the call before writing anything. #### How far back should a food hub's baseline data go for a grant application? Twelve full months is the practical minimum, because seasonality makes shorter periods misleading. Twenty-four months is better, since it lets you show a trend rather than a snapshot and gives the assessor confidence the baseline is not a one-off spike. If you have less than a year of records, say so explicitly and use the partial period with a stated date range rather than annualising an estimate. #### Can I use estimates from published studies in a grant application? Yes, for context in the needs analysis, as long as you cite the study and keep it clearly separate from your own figures. What you should not do is use borrowed multipliers as your project baseline or indicator target, because you will be asked to report against them with your own data. Keep the distinction visible: external literature frames the problem, your records set the baseline. #### What happens if a co-op misses a grant indicator target? Most schemes distinguish between underperformance and non-compliance. Missing a target with a documented explanation, for example a producer withdrawal or a route suspension recorded at the time, is usually handled through the narrative and may trigger a partial correction. Missing a target you cannot measure at all is more serious, because it looks like the monitoring obligation was never met. This is why dated monthly exports and a change log matter more than a polished final document. #### Do I need separate software for grant reporting, or can operational data cover it? Operational data covers indicator measurement, activity evidence and producer income reporting, which is the bulk of the narrative burden. Financial claims against eligible cost categories still belong in accounting, with procurement and payment trails. The integration point is keeping payouts, commissions and delivery costs separated per order so operations figures and accounting figures reconcile without manual unpicking. ### Sources - [canr.msu.edu](https://www.canr.msu.edu/news/increased-local-food-sales-to-schools-and-the-value-of-grant-investment-findings-from-the-2025-national-food-hub-survey) - [grants.ca.gov](https://www.grants.ca.gov/grants/farm-to-community-food-hubs-grant-program/) - [goodgrants.com](https://goodgrants.com/resources/articles/grant-reporting-best-practices-6-ways-to-leverage-data/) - [sopact.com](https://www.sopact.com/use-case/impact-reporting-software) - [formomentum.com](https://formomentum.com/tech-for-good-part-iii-social-impact-reporting/) --- ## Build vs Buy for a Food Hub: The Five-Year Cost of the Custom Platform You Nearly Commissioned URL: https://plodie.com/posts/build-vs-buy-for-a-food-hub-the-five-year-cost-of-the-custom-platform-a-co-op-ne Published: 2026-09-10 · Category: Business · By: Ivan Lauc A realistic five-year cost breakdown of building a custom food hub platform in-house versus buying vertical software: maintenance, security patching, GDPR obligations, payout logic changes and the internal expertise nobody budgets for. ### 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](https://plodie.com/posts/why-generic-software-fails-short-food-supply-chains-the-case-for-vertical-saas-b), 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. ### Sources - [hbs.edu](https://www.hbs.edu/faculty/Pages/item.aspx?num=51343) - [nist.gov](https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-supply-chain-security-guidance-13) - [developer.ibm.com](https://developer.ibm.com/articles/s-gdpr1/) - [savibm.com](https://savibm.com/blog/software-maintenance-costs/) - [adevs.com](https://adevs.com/blog/software-maintenance-costs/) --- ## The Order That Arrived by WhatsApp: Merging Web Baskets, Phone Calls, Standing Boxes and Restaurant Emails Into One Order Book URL: https://plodie.com/posts/the-order-that-arrived-by-whatsapp-how-a-co-op-merges-web-baskets-phone-calls-st Published: 2026-09-09 · Category: Product · By: Ivan Lauc A local food co-op receives orders through four different channels, and only one of them is the storefront. Here is how to normalise phone calls, standing subscriptions and restaurant emails into a single order book before cut-off, without double-booking households or drifting producer stock. ### Why a co-op's order book never comes from the storefront alone Most local food co-ops receive orders through at least four channels: the shopper app basket, phone calls to the office, recurring standing boxes, and email or messaging orders from restaurants and other trade buyers. Only the first one produces a clean order record by itself. The other three arrive as human conversation. At Plodovi.hr, a co-op of around 38 producers, this is not a transitional state that a better storefront will eliminate. The phone call exists because an older customer trusts a voice more than a checkout button. The standing box exists because a household does not want to shop weekly. The restaurant email exists because a chef writes their order while doing stock at 23:00 and will not open an app to do it. Through the Ajmo Lokalno pilot, HoReCa orders arrive with different quantities, different units and different price expectations than a household basket. The mistake is treating each of these as a different kind of business. They are not. They are four different ways of saying the same sentence: this buyer wants this quantity of this producer's product for this fulfilment date. Everything after intake, picking, splitting, routing, payout, is identical. If the intake channel leaks into the downstream logic, you end up maintaining four half-broken order systems instead of one. ### What a manual order record must actually contain A phone or email order needs every field the storefront collects automatically, entered by hand: buyer identity, delivery or pickup point, fulfilment date and slot, each line item with producer, product, quantity and unit, agreed price, payment method and status, and a source tag recording where the order came from and who entered it. Miss one and it surfaces later as a pick error or an unpaid box. The fields people forget are the boring ones. Unit is the most dangerous: a chef says "ten kilos of potatoes" and a household says "two bags", and if the admin types 10 against a product priced per bag, the producer gets a payout request for something they never declared. Price is the second: trade buyers often have an agreed list that differs from retail, so a manual order needs a price source, not just a number. Payment status is the third: a phone order is frequently pay-on-delivery, which means the driver needs to know and the reconciliation run needs to expect cash. We also record who took the order and when. Not for blame. When a customer says "I asked for chard, not spinach", the only way to close that conversation in a minute is to look at the order note, see that it was entered by the office on Wednesday at 10:14 with a note saying chard was unavailable, and either fix it or explain it. - Buyer: existing account, or a new one created at intake, never a free-text name - Fulfilment: date, delivery point or pickup slot, address if home delivery - Lines: producer, product, quantity, unit, price and price source (retail or trade list) - Payment: method, status, and who collects it if it is cash on delivery - Provenance: source tag (app, phone, standing, HoReCa email), entered-by user, timestamp - Notes: substitutions agreed verbally, access instructions, packaging returns ### The duplicate problem: one household, two orders Double-booking happens when a household places a web basket and also phones the office, or when a standing box runs in the same week the customer ordered manually. The fix is to force every manual order onto an existing buyer account and to show the admin any open order for that buyer and fulfilment date before the entry can be saved. The failure is quiet and expensive. Two orders for the same household in the same week means two boxes picked, two stops routed to the same door, and a refund conversation on delivery day. Worse, it consumes producer stock twice, so something else that could have been sold shows as unavailable. Before we tied manual entry to accounts, the office had no way to see the web basket at all. The order existed, it just was not in front of the person on the phone. Two rules removed almost all of it. First, no manual order without a buyer record, so the search field is the account list and creating a new customer is a deliberate act rather than the default. Second, when an admin opens manual entry for a buyer with an open order for that cycle, the system offers to add lines to the existing order instead of creating a second one. Merge, do not stack. The remaining duplicates are the genuinely ambiguous ones, a household ordering a gift box for a relative at the same address, and those are resolved by a human looking at the two orders side by side. ### A manual order still has to consume declared stock Every order, no matter how it arrived, must decrement the producer's declared availability for that cycle. If phone and email orders bypass the availability ledger, the storefront keeps selling produce that is already committed and the declared numbers drift away from what can actually be picked. This is the rule that people are most tempted to break, because it is inconvenient. A chef wants 12 kilos of tomatoes and only 9 are declared. The easy path is to type 12 anyway and sort it out later. The honest path is that the order line either takes the 9 available and flags a shortfall, or the admin contacts the producer and gets the declaration raised before the line is accepted. Our producers post availability weekly rather than running live inventory, which makes the ledger the single source of truth for the cycle and makes an override visible rather than silent. Overrides still exist, because reality does. What changed is that an override is a recorded event with a reason and a named producer to confirm it, not an untracked number in a cell. When declared, ordered and delivered quantities are all held against the same product for the same cycle, the weekly variance report tells you which producers over-declare and which channel is generating the shortfalls. Usually it is the trade channel, because restaurant quantities are large enough to consume a small producer's entire week in one line. ### What broke with standing orders, and the change we made Standing subscriptions used to generate their orders on a schedule regardless of what producers had declared for that week. The result was orders containing produce nobody had available, discovered at picking. We changed generation to happen after the declaration window closes, and to resolve each line against actual availability before the order is confirmed. The original design felt reasonable. A standing box is a promise, so create the order early and let the pick list deal with it. But a standing box in a short supply chain is a promise about a category, not a specific item. Nobody can promise fennel in week 34. When the generator wrote fixed lines on Sunday and producers declared on Tuesday, the mismatch surfaced on Thursday night in front of a volunteer holding a crate. The sequence now runs in this order, and the customer-facing consequence is that a standing order is only final once availability exists to support it. - Declaration window closes for the cycle, producer availability is locked - Standing order templates generate draft orders against that availability - Lines that cannot be filled are substituted per the customer's stored substitution preference, or dropped - The customer receives the draft contents with a window to edit or skip before the order cut-off - At cut-off, drafts confirm, stock is consumed, and the orders join the same book as app, phone and HoReCa orders ### One order object with a source tag, not four pipelines The architectural decision that mattered most was refusing to build channel-specific order pipelines. There is one order object. The channel is a field on it, not a separate table, workflow or codebase. Everything downstream, pick lists, producer splits, routing, invoicing and payouts, reads the same structure regardless of how the order arrived. We started down the other road. A phone order looked different enough from a web order to justify its own handling, and a restaurant order looked different again with its trade prices, larger quantities and invoice-on-terms payment. Two channels in, we were writing the pick-list logic for the third time and the three versions had already diverged on rounding. Consolidating them meant accepting that some fields are only populated for some channels, a HoReCa order carries a company VAT number and a payment term, a phone order carries an entered-by user, a standing order carries a template reference. Nullable fields are a much smaller cost than parallel pipelines. The source tag then earns its keep as reporting. You can see what share of revenue arrives outside the storefront, which is usually higher than anyone expects, which channels produce the most substitutions and shortfalls, and whether the app is actually absorbing phone customers over time or just adding new ones. That last number decides whether you invest in reducing manual intake or in making manual intake faster. For most co-ops we work with, the honest answer is the second one, which is why Plodie treats manual order entry as a first-class administrator workflow rather than an escape hatch. ### Key Takeaways - A co-op's order book comes from at least four channels: app baskets, phone calls, standing subscriptions and restaurant email orders. Only the first is self-documenting. - Manual orders need every field the storefront captures automatically, plus a source tag, an entered-by user and a price source for trade buyers. - Force manual entry onto existing buyer accounts and surface open orders for the same cycle, or you will pick, route and refund the same household twice. - Manual and standing orders must consume declared producer availability, otherwise the storefront keeps selling produce that is already committed. - Generate standing-box orders after the declaration window closes, not on a fixed schedule, and give the customer an edit window before cut-off. - One order object with a channel field beats four channel-specific pipelines. Nullable fields are cheaper than divergent pick-list logic. The stock ledger these rules depend on is described in detail in our [declaration-based availability model](https://plodie.com/posts/the-tuesday-night-text-message-how-38-producers-declare-next-week-s-availability), including the six rules that keep declared numbers close to delivered ones. ### Frequently Asked Questions #### How do you manage orders for a local food co-operative that still takes phone calls? Treat the phone call as an intake method, not a separate order type. The person taking the call enters the order against an existing buyer account in the same system the storefront writes to, filling in fulfilment date, line items with units, agreed price and payment method, and tagging the source as phone. Everything downstream then behaves identically to a web order. #### Should a food co-op accept orders over WhatsApp? It is fine to accept them, as long as WhatsApp is only the message and not the record. Someone has to transcribe the message into a real order record with buyer, date, line items and units the same day, and the original message should be referenced in the order notes so any dispute can be checked. Leaving orders to live in a chat thread is where double-bookings and forgotten lines come from. #### What is the difference between a retail basket and a HoReCa order in a co-op platform? Structurally they are the same order object, but a HoReCa order usually carries trade prices from an agreed list, larger quantities in bulk units, a company VAT number, and payment on invoice terms rather than at checkout. It also often needs a delivery window tied to kitchen prep times. Those are extra fields on the order, not a separate system. #### How do you stop a standing subscription box from ordering produce that is out of season? Generate the order after producers have declared availability for the cycle rather than on a fixed schedule, then resolve each template line against what is actually available. Unfillable lines follow the customer's stored substitution preference or are dropped, and the customer sees the resulting draft contents with a window to edit or skip before cut-off. #### What happens if two orders exist for the same household in the same week? Merge them rather than fulfilling both. A good system flags any open order for the same buyer and fulfilment date when an admin starts a manual entry, and offers to add the new lines to the existing order. If both were already confirmed and picked, you are choosing between a refund on delivery day and a second van stop, which is exactly the cost the duplicate check is there to avoid. ### Sources - [docs.oracle.com](https://docs.oracle.com/en/cloud/saas/supply-chain-and-manufacturing/26a/faiom/overview-of-integrating-order-management-with-subscription-management.html) - [netguru.com](https://www.netguru.com/blog/order-management-challenges) - [oracle.com](https://www.oracle.com/retail/omnichannel/products/tips-to-resolve-five-retail-order-management-challenges/) - [cin7.com](https://www.cin7.com/blog/multichannel-order-management-system/) - [tejassoftware.com](https://www.tejassoftware.com/en/knowledge-center/blog/oms-unified-multi-channel-order-management-complete-operational-control.aspx) --- ## Why Generic Software Fails Short Food Supply Chains: The Case for Vertical SaaS Built by an Operator URL: https://plodie.com/posts/why-generic-software-fails-short-food-supply-chains-the-case-for-vertical-saas-b Published: 2026-09-08 · Category: Business · By: Ivan Lauc ERPs and e-commerce platforms fail short food supply chains at the data model, not the feature list. Here is why multi-producer, perishable, route-bound operations need vertical software, and what changes when the people building it also run a co-op. ### 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](https://plodie.com/posts/why-shopify-breaks-at-the-second-producer-what-happens-to-payouts-stock-and-pick), 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. ### Sources - [itradenetwork.com](https://www.itradenetwork.com/resources/why-erps-arent-enough-for-modern-food-supply-chains) - [theowlsolutions.com](https://theowlsolutions.com/erp-limitations/) - [order.co](https://www.order.co/blog/procurement/limitations-of-erp/) - [bizowie.com](https://bizowie.com/the-complete-guide-to-erp-for-consumer-goods-solving-modern-supply-chain-challenges) - [bissano.com.au](https://bissano.com.au/insights/generic-software-fails/) --- ## Forecasting Next Week's Kale With 180 Data Points: Where Machine Learning Helps a 38-Producer Co-op, and Where a Moving Average Wins URL: https://plodie.com/posts/forecasting-next-week-s-kale-with-180-data-points-where-machine-learning-actuall Published: 2026-09-07 · Category: AI · By: Ivan Lauc Demand forecasting advice assumes millions of rows. A short food supply chain has a few hundred. Here is what is actually predictable on small-N local food data, which signals matter, and when a three-week moving average beats a model. ### How much data does a 38-producer co-op actually have? A weekly co-op with 38 producers and two years of trading has roughly 100 weekly cycles, and for any single product perhaps 60 to 90 weeks where that product was even available. Kale sold across 12 autumn and winter weeks a year gives you around 24 observations, not thousands. The number in the title is generous. Take one product, one channel, one co-op: kale, home delivery boxes, weekly ordering window. Two seasons of trading might produce 180 order lines in total, spread across perhaps 24 sales weeks and 90 distinct shoppers. That is the entire training set. Aggregate to the level you actually need to forecast, which is kilograms of kale to request from producers for next week, and you have 24 numbers. This matters because almost every published guide to AI demand forecasting assumes the opposite problem. Those articles are written for a distributor with 400 SKUs, five depots and six years of daily transactions, where the challenge is compute and feature engineering. In a short food supply chain the challenge is that half your products have fewer observations than a school science experiment, and the ones with more observations have their seasonality baked in so hard that a model can memorise the calendar and learn nothing else. ### Where a three-week moving average wins For any product with a stable weekly rhythm and no strong trend, a three-week moving average of recent sales, adjusted by hand for known events, beats a trained model on small local data. It is transparent, needs no maintenance, survives missing weeks, and fails in ways an administrator can see and correct. The reason is variance. With 24 observations and 10 candidate features, a model will fit noise and present it with a confidence the data does not support. A moving average makes one assumption, that next week resembles the last three, and that assumption is correct most of the time in a weekly delivery co-op with a repeat shopper base. Where it is wrong, it is wrong by a small, bounded amount. Simple statistics are the right tool in most of the cases a co-op administrator faces week to week. - Products with fewer than roughly 20 sales weeks of history: there is nothing for a model to learn that a human cannot read off a chart. - Products with flat demand and high repeat purchase, such as eggs, potatoes, bread and milk: the previous three weeks are close to a perfect predictor. - A brand new producer or a new product: no history at all, so use a comparable product's curve and a conservative first-week quantity. - One-off shocks such as a heatwave, a road closure or a festival: judgement plus a manual override beats any historical pattern. - Anything where the cost of being wrong is low: if unsold bunches go to the co-op's own market stall, precision has little value. ### Where prediction genuinely helps on small local data Machine learning earns its place in a short food supply chain not on total demand but on structure: which shoppers are about to lapse, which order lines a shopper reliably repeats, which weeks a seasonal product will peak, and which producer declarations habitually overstate what arrives. These have more observations per prediction than product-level demand does. The trick is to change the unit of analysis. Forecasting kilograms of kale gives you 24 rows. Forecasting whether a given shopper will order kale next week, given their last eight weeks of baskets, gives you 90 shoppers times 24 weeks, which is over 2,000 rows with genuine variation in it. Shopper-level repeat prediction is a small-data-friendly problem because the panel is wide even when it is short. Summing individual probabilities then gives you a demand estimate that carries an honest confidence interval, because you know how many shoppers it rests on. The same shift works elsewhere. Declaration reliability is a per-producer, per-week problem with hundreds of observations across the co-op, so a simple model can learn that producer 14's leafy greens arrive at 85 percent of declared weight in July and 100 percent in October. Basket completion, delivery failure risk and slot demand all have similar shapes: many small events rather than few big aggregates. ### Which signals matter in a short food supply chain Five signal families carry almost all the predictive power in local food demand: calendar position in the growing season, weather in the ordering window, holiday and school weeks, repeat shopper cohort behaviour, and catalogue composition, meaning what else was available to order that week. Everything else is usually noise at this data volume. Season is not a smooth sine wave here. It is a set of hard on/off gates: the first week tomatoes appear, the week strawberries end, the week the co-op's only kale grower starts cutting. A model that treats week-of-year as a continuous feature will smooth across those edges and be confidently wrong at exactly the transitions that matter. Encoding availability windows explicitly, per product per producer, does more than any algorithm choice. Weather works differently from the industrial case too. It affects supply through the producer's field, and it affects demand through the shopper's cooking plans, often in opposite directions in the same week. A cold snap raises soup vegetable orders and slows growth in the tunnel. Catalogue composition is the signal most co-ops forget: kale sales drop when chard, spinach and cabbage all appear the same week, so a kale forecast that ignores substitution will over-order every time the greens overlap. - Season and availability windows: explicit per-product start and end weeks, not a continuous week-of-year term. - Weather: temperature and rain during the ordering window, with separate treatment of the supply effect and the demand effect. - Calendar events: public holidays, school terms, local festivals, and the week before and after each. - Cohort behaviour: weeks since a shopper joined, purchase frequency, and whether they are in their first four orders or their fortieth. - Catalogue composition: how many substitute products were listed that week, and at what price relative to each other. ### A practical forecasting ladder for a co-op Start with a moving average, add manual overrides, then add seasonal adjustment, then add shopper-level repeat probability, and only then consider a trained model. Each rung should be shipped and used before the next is built, because each one absorbs error the next rung would otherwise be asked to explain. In practice most co-ops should stop at rung three or four for a long time. Rung one costs an afternoon of SQL. Rung two is a text box next to a number in the admin interface, plus a habit of using it. Rung three encodes availability windows and holiday weeks, which produces most of the accuracy gain a co-op will ever see from forecasting. Rung four is where the shopper-level panel comes in, and it is the first rung where anything deserving the label machine learning appears. Measure honestly at each rung. Track mean absolute error in the unit the operation cares about, which is kilograms or units per product per week, and track it against the naive baseline of last week's sales. If a new rung does not beat the naive baseline by a margin larger than the week-to-week noise, it has not earned its place. Also track the asymmetry: over-ordering leafy greens costs waste and a producer credit note, while under-ordering costs a missing line in 40 boxes and an apology. A forecast that is unbiased in aggregate but wrong in the expensive direction is worse than a slightly biased one. - Rung 1: three-week moving average per product, shown next to the declaration screen. - Rung 2: administrator override with a required one-line reason, logged for later review. - Rung 3: seasonal gating and holiday-week multipliers derived from last year's same weeks. - Rung 4: shopper-level repeat probability summed to a product forecast with a confidence range. - Rung 5: a gradient-boosted or regularised regression model on the full signal set, evaluated against rung 4 before it is trusted. ### How to tell a real forecast from a confident guess A usable forecast in a short food supply chain states a range, names the number of observations behind it, and shows what it assumed. A number with no interval and no history count is a guess wearing a decimal point, and producers stop trusting it the first week it is badly wrong. This is a product design problem more than a modelling one. If the admin interface says 42 kg of kale, an administrator will order 42 kg. If it says 34 to 50 kg, based on 19 comparable weeks, no kale sold in 3 of the last 8 weeks, the same administrator asks a producer a question and lands somewhere sensible. The interval is not a hedge, it is the information. On small-N data, honestly wide intervals are the correct output, and narrow ones should be treated as a bug. The trust economy matters as much as the arithmetic. Producers plan cutting and harvest around what the co-op asks for, so a forecast that quietly over-asks pushes waste and cost onto the grower rather than the co-op. Any forecasting feature in local food should be introduced as a suggestion beside the human decision, never as an automatic order, and its historical accuracy per product should be visible to the people whose week it shapes. ### Key Takeaways - A single product in a weekly co-op typically has 20 to 30 usable observations, not thousands, so most published AI forecasting advice does not transfer. - For flat, high-repeat products and anything with under about 20 sales weeks of history, a three-week moving average plus manual overrides beats a trained model. - Prediction pays off when you change the unit of analysis: shopper-level repeat probability, declaration reliability and slot demand have wide panels even on short histories. - The signals that matter locally are availability windows, ordering-window weather, holiday and school weeks, cohort age and catalogue substitution, not generic trend and price elasticity. - Always publish a range and the observation count, and measure every rung against the naive last-week baseline before trusting it. The declaration data these forecasts depend on is described in our [Tuesday night declaration post](https://plodie.com/posts/the-tuesday-night-text-message-how-38-producers-declare-next-week-s-availability), which covers how producers post next week's availability and the rules that keep those numbers honest. ### Frequently Asked Questions #### Can you do demand forecasting with only one year of sales data? Yes, but only at the coarsest level. One year gives you a single observation of each seasonal week, which is enough to gate availability windows and flag holiday weeks, but not enough to separate a real seasonal effect from one unusual week. For the first year, use a moving average for near-term quantities and treat last year's same week as a sanity check rather than a prediction. #### What forecast accuracy should a small food co-op expect? Judge accuracy relative to the naive baseline rather than against an absolute target. For stable staples like eggs and potatoes, a moving average often lands within 10 to 15 percent of actual weekly volume. For weather-sensitive leafy greens and soft fruit, errors of 30 percent or more are normal, which is why range-based forecasts and manual overrides matter more than model sophistication. #### Is it worth buying an AI demand forecasting tool for a food hub? Usually not as a separate purchase. Off-the-shelf forecasting tools expect long daily transaction histories and hundreds of stable SKUs, neither of which a food hub has. The higher-value investment is clean order-line and declaration data inside the platform you already run, plus simple baselines surfaced where decisions are made. #### How do you forecast demand for a brand new product or producer? Borrow a curve from the closest comparable product already in the catalogue, then start deliberately small. Order a conservative first-week quantity, watch the sell-through rate and the share of shoppers who add it, and adjust in the second and third weeks. After four or five weeks you have enough to switch to a moving average of its own history. #### What is the difference between forecasting supply and forecasting demand in a short food supply chain? Demand forecasting predicts what shoppers will order; supply forecasting predicts what producers will actually deliver against what they declared. Both are needed, because a co-op's real constraint is the smaller of the two. Supply-side prediction is often the easier win, since declaration versus delivered weight is recorded every week across all producers, giving far more observations than any single product's sales history. ### Sources - [pmc.ncbi.nlm.nih.gov](https://pmc.ncbi.nlm.nih.gov/articles/PMC12215695/) - [arxiv.org](https://arxiv.org/abs/2104.13246) - [scholarworks.lib.csusb.edu](https://scholarworks.lib.csusb.edu/etd/1914/) - [stxnext.com](https://www.stxnext.com/blog/machine-learning-in-forecasting-vs-traditional-forecasting-methods) - [genpact.com](https://www.genpact.com/insight/the-evolution-of-forecasting-techniques-traditional-versus-machine-learning-methods) --- ## The Social Impact Report a Co-op Can Actually Defend: Turning Transaction Data Into Local Spend, Jobs and Food Access Numbers URL: https://plodie.com/posts/the-social-impact-report-a-co-op-can-actually-defend-turning-transaction-data-in Published: 2026-09-07 · Category: Business · By: Ivan Lauc Most local food impact claims are estimates borrowed from someone else's study. Here is how a co-op derives local spend, producer income, jobs supported and food access figures from the order lines, payouts and delivery records it already holds. ### Why most co-op impact reports fall apart under questioning Most local food impact reports fail because the numbers are borrowed, not measured. A co-op quotes a multiplier from a national study, applies it to its own turnover and prints a figure it cannot trace back to a single transaction. When a funder asks how the number was produced, the trail stops at someone else's research paper. The second failure mode is the opposite: a genuine internal number calculated once, by hand, in a spreadsheet, from an export that has since been overwritten. It was probably correct in the month it was made. Nobody can reproduce it a year later, and nobody can explain which orders were included, whether cancelled orders were stripped out, or how a producer who moved premises mid-year was treated. A defensible impact report has three properties. Every figure traces to rows in an operational system, not to an assumption. The method is written down in enough detail that a different person running it next year gets the same answer from the same data. And the boundaries are stated openly, including what the co-op chose not to count. That last property matters more than precision. A funder rarely challenges a modest number that is honestly bounded; they challenge a large number with no visible derivation. ### The five numbers worth reporting, and the fields each one needs Five metrics cover most of what funders, members and local authorities actually ask for: total spend with local producers, percentage of revenue retained locally, producer income and price share, jobs and livelihoods supported, and food access reach. Each maps to fields a co-op platform already stores against orders, payouts and producer records. The discipline is to define each metric as a query before you calculate it. Write down the table, the date range, the filter and the exclusions. If you cannot express the metric as a query over data you hold, you are about to estimate something, and it should be labelled as an estimate in the report. - Local producer spend: sum of settled payout lines to producers, by period, filtered to producers whose registered premises fall inside your defined local radius or administrative area. - Revenue retained locally: local producer payouts plus co-op wages, plus locally sourced operating costs (packaging, fuel, van maintenance from local suppliers), divided by gross sales. - Producer income and price share: producer payout as a percentage of shelf price per order line, plus average price per unit compared with the producer's own wholesale reference price where they supply one. - Livelihoods supported: producers with sales above a stated threshold in the period, split into full-time-equivalent bands using declared farm labour, plus co-op staff and paid driver hours from delivery records. - Food access: distinct delivery postcodes served, deliveries into areas you have classified as underserved, donated volume and value, subsidised or reduced-price box counts, and pickup points within walking distance of served addresses. ### How to compute local spend and revenue retention without inventing a multiplier Local spend is the sum of what the co-op actually paid producers and local suppliers in the period, taken from settled payout and purchase records rather than from sales. Revenue retention is that sum divided by gross sales for the same period. No multiplier is required, and none should be applied unless it is separately labelled as a modelled estimate. The mechanics matter. Use settled payouts, not gross order value, because gross order value includes commission, delivery charges, packaging deposits and VAT that never reach a producer. Use the payout period, not the order period, and say which you used. Exclude cancelled and refunded lines, and exclude producer credits issued for quality complaints, or state that you included them. If a producer resells goods they did not grow, either separate those lines or note the limitation, because a funder who knows the sector will ask. Defining local is a policy decision, not a data decision, and it belongs at the top of the report. A radius in kilometres from the hub, a county or administrative boundary, and a national border produce three different answers from the same rows. Pick one, publish it, and keep it stable year on year so the trend line means something. If you must change it, restate the prior year on the new definition alongside the old figure. Multipliers can still appear, in a clearly separated section, showing what the local spend figure would imply under a published regional model, with the source cited and the modelled figure never mixed into the measured one. ### Turning payouts and delivery records into jobs supported and fair pricing evidence Jobs supported is the metric most likely to be inflated and the one most worth doing carefully. Report it as three separate, clearly labelled components: co-op employment measured directly from payroll and driver hours, producer livelihoods measured as businesses reaching stated revenue thresholds, and, if you want it, a modelled full-time-equivalent estimate that is presented as a model and nothing else. Producer livelihoods work best as banded counts rather than a single converted number. Say how many producers earned above a threshold that represents meaningful supplementary income, how many earned above a threshold that represents a substantial share of a small farm's turnover, and how many are new to the co-op this year. That statement is fully defensible: it is a count of businesses against payout totals you can show. Converting it to a jobs figure requires knowing each producer's total income across all channels, which you do not hold, so any conversion needs the producer's own declaration or must be flagged as an assumption. Fair pricing evidence comes from the same payout data seen per line. For each order line you know the shelf price, the commission, the delivery contribution and the producer's share. Report the average producer share of shelf price by category, since it will differ between a leafy green with high spoilage and a jar of honey. Where a producer also sells wholesale and is willing to share a reference price, the gap between that price and the co-op price is the clearest direct-sale gain you can publish. Do not compute it from supermarket shelf prices you scraped; that comparison invites an argument about product grade you will not win. ### Making food access measurable when you only see orders Food access is the hardest metric to evidence honestly, because delivery records show where food went but not who could not afford it. The defensible version reports reach and provision: distinct addresses and postcodes served, coverage of areas you have classified as underserved using published deprivation or food desert data, donated volume, and counts of subsidised, sliding-scale or voucher-funded boxes. Postcode-level analysis is the workhorse here. Aggregate deliveries to postcode districts, join those to a public deprivation or rural access dataset, and report the share of orders and volume delivered into the lower bands. Report it as coverage, not as impact: the co-op delivered a stated volume into these areas, which is a fact, rather than the co-op improved food security, which is a claim requiring evidence you do not have. Keep the aggregation coarse enough that individual households are never identifiable in a published report. Donations and volunteering deserve their own capture path rather than being reconstructed at year end. If surplus routed to a food bank is recorded as a donation order type with the same weight and product data as a sale, the annual figure is a query rather than a memory exercise, and the food waste diverted number falls out of the same rows. Volunteer hours logged against picking or delivery sessions give you a labour contribution figure that pairs naturally with the jobs section. Both are small features that turn an anecdote into a line item. ### Publishing a report that survives an auditor and a journalist Publish the numbers with their method attached. Every headline figure should carry the data source, the period, the definition of local, the exclusions applied and whether it is measured or modelled. A one-page methodology appendix does more for credibility than another chart, and it is what an auditor, a grant officer or a sceptical journalist will turn to first. Structure the report so measured and modelled numbers never share a sentence. Lead with the measured set: producer payouts, retention percentage, producer counts by band, postcodes served, donated kilograms, volunteer hours. Follow with a clearly headed modelled section if you want multiplier effects or estimated full-time equivalents, citing the model's source and showing the input you fed it. Close with limitations, stated plainly: what you cannot see, which producers resell, which sales channels are outside the platform, where a definition changed. Then run it again next year on the same definitions. A single-year impact report is a marketing asset; a three-year series on stable definitions is evidence, and it is what turns a grant application or a local authority procurement conversation. This is also why the calculation belongs in the operational system rather than in a consultant's spreadsheet. Plodie holds the order lines, producer records, settled payouts and delivery data in one place, which means these figures are queries over live operational data rather than an annual archaeology project, and the same rows that pay a grower this week produce the impact number next January. ### Key Takeaways - Impact numbers are only defensible when each one traces to rows in an operational system, with the period, filters and exclusions written down. - Use settled producer payouts rather than gross sales for local spend, since gross order value includes commission, delivery, deposits and VAT that never reach a grower. - Define 'local' as a stated policy (radius, county or national border), publish it, and keep it stable so year-on-year trends mean something. - Report jobs as banded producer counts plus actual co-op payroll and driver hours; keep any full-time-equivalent conversion in a separate, clearly labelled modelled section. - Capture donations, subsidised boxes and volunteer hours as data at the moment they happen, not as a year-end reconstruction. For the environmental half of the same impact story, see our [food miles report companion piece](https://plodie.com/posts/the-food-miles-report-a-co-op-can-actually-produce-turning-delivery-routes-produ), which covers route distances, producer coordinates and waste from the same underlying order data. ### Frequently Asked Questions #### What is a local food multiplier and should a co-op use one in its impact report? A local multiplier estimates how many times a euro spent locally recirculates in the local economy before leaving it, usually drawn from regional economic studies. A co-op can cite one, but it should sit in a clearly separated modelled section with the source named and the input shown, never blended into measured figures like producer payouts. Funders generally accept modelled numbers that are labelled as such and challenge ones that are not. #### How often should a food co-op produce a social impact report? Annually is the practical rhythm for a published report, aligned to your financial year so the sales and payout figures reconcile with your accounts. If the underlying metrics are queries over live data rather than manual work, run them quarterly internally so you spot a falling retention percentage or a shrinking producer base in time to act. The published version should always use the same definitions as the previous year. #### Can a co-op report on food access without collecting income data from shoppers? Yes, and in most cases it should. Reporting delivery coverage by postcode district joined to public deprivation or rural access data, plus counts of subsidised boxes, voucher redemptions and donated volume, gives an evidenced picture of reach without asking households about income. Collecting income data creates a special-category-adjacent GDPR burden that a small co-op rarely needs to take on. #### What data do funders and local authorities usually ask a food co-op for? Most commonly: total spend with local producers, number of producers supported and how many are new, geographic coverage of deliveries or pickup points, employment and volunteer contribution, and any provision to low-income or underserved households. They also increasingly ask how figures were calculated, so keeping a one-page methodology appendix with each report saves a round of follow-up questions. #### How do you calculate the producer's share of the shelf price? For each order line, divide the producer's settled payout by the shelf price the shopper paid, before or after VAT depending on your stated convention, and average it by product category rather than across the whole catalogue. Categories with high spoilage or heavy handling carry different margins, so a single blended figure hides the detail a producer or funder actually wants to see. ### Sources - [content.ces.ncsu.edu](https://content.ces.ncsu.edu/local-food-systems-clarifying-current-research) - [canr.msu.edu](https://www.canr.msu.edu/foodsystems/resources/webinar/Evaluating%20the%20Economic%20Impacts%20of%20Local%20and%20Regional%20Food%20Systems-%20Best%20Practices%20Webinar.pdf) - [ageconsearch.umn.edu](https://ageconsearch.umn.edu/record/313446/files/JFDR52.1_4_Ajayi.pdf) - [ers.usda.gov](https://www.ers.usda.gov/data-products/food-access-research-atlas) - [pubmed.ncbi.nlm.nih.gov](https://pubmed.ncbi.nlm.nih.gov/26494034/) --- ## The Tuesday Night Declaration: How Producers Post Next Week's Availability in Under Four Minutes, and the Six Rules That Keep the Numbers Honest URL: https://plodie.com/posts/the-tuesday-night-text-message-how-38-producers-declare-next-week-s-availability Published: 2026-09-05 · Category: Product · By: Ivan Lauc How small producers actually track stock and availability in a short food supply chain: a declaration-based model instead of running inventory, the six rules that stop declared numbers drifting from delivered ones, and the two rules that were removed after producers ignored them. ### Why a running inventory count fails a grower who harvests to order A running inventory model assumes stock exists in a countable place before it is sold. For a grower who harvests to order, it does not. The lettuce is in the ground on Tuesday and in a crate on Friday morning, so any warehouse-style count is a guess dressed up as a fact. The first version of the producer app asked the obvious question: how many units do you have? Growers either left it blank or entered a number and never decremented it, because decrementing implies you are drawing down from a pile. A market gardener with three beds of chard has no pile. She has a rate of regrowth, a weather forecast, and a rough sense of how much she is willing to cut for a Friday delivery without wrecking the following week. The question that works is different: how much will you commit to deliver into the window that closes Thursday at 18:00? That is a promise about a future act, not a measurement of a present object. It is answerable in a field, on a phone, with wet hands. It also carries a clean failure mode, because a broken promise is something an administrator can chase, whereas a wrong count is something nobody can attribute. ### What the declaration screen actually asks for Each product line asks for one number and one window. The number is a declared quantity the producer is willing to deliver, and the window is the fixed delivery cycle it belongs to. Everything else is pre-filled from last week: the same lines, the same units, the same prices, in the same order. The speed comes almost entirely from that pre-fill. A producer who sells the same eight lines every week is not composing a catalogue, she is editing last week's. The common interaction is three taps: open, adjust two numbers, confirm. Lines that are genuinely out of season get zeroed, which is a different act from leaving them undeclared, and the interface keeps those two states visually distinct because they mean different things downstream. The unit matters as much as the number. Declaring in the unit the producer harvests in, bunches, crates, kilos, heads, removes a conversion step that used to be done in the producer's head and got the decimal wrong. If the shopper catalogue needs a different unit, the conversion belongs in the platform, not in a tired person's arithmetic at nine in the evening. - Declared quantity: what I will bring to pack-down for this window - Delivery window: fixed, not chosen per line - Unit: the producer's harvest unit, converted downstream if needed - Zero: declared as unavailable this week - Blank: no declaration made, which is treated as hidden, not zero ### The six rules that stop declared numbers drifting Six rules govern what happens between the declaration and the crate on the van. Each one exists because a specific gap opened between what a producer declared, what shoppers committed to buy, and what arrived at pack-down. Together they turn a soft promise into something an administrator can plan a route around. The rules are deliberately mechanical. None of them asks the producer to do extra work in the normal case, and each one only surfaces when a number moves. That constraint is what makes them survivable in an operation where the average producer touches the app twice a week. - Rolling carry-over. Declared stock that goes unsold does not silently vanish at window close. It is offered back as the default for the next window, so the producer confirms or trims rather than re-entering a number from nothing. - Per-line cap on shared lines. When several producers supply the same catalogue line, each one's declared quantity is a hard ceiling on what can be allocated to them. No single producer can absorb the whole line's demand because their number happened to be entered first. - Stale-declaration expiry. A declaration that is never confirmed after the ordering window opens is pulled off the shopper catalogue after a set number of hours. The line goes hidden rather than staying live and selling stock nobody promised. - Partial-commit acknowledgement at pack-down. When a producer arrives with less than the committed quantity, they acknowledge the shortfall in the app at hand-over. That converts a silent gap into a timestamped event before the boxes are packed, not after a shopper complains. - Under-delivery reconciliation. Repeated shortfalls on a line adjust the default declared quantity the app suggests next week. The producer can override it, but the starting point moves toward what they actually deliver. - No-declaration default is hidden, not zero-priced. A producer who declares nothing disappears from the catalogue for that window. They are not shown as sold out, and they are never shown with a price and no stock behind it. ### The two rules that were removed after producers ignored them Two rules did not survive contact with the field: a mandatory reason code for reducing a declaration, and a mid-week re-declaration prompt. Both were technically sound, both produced clean data on paper, and both were routed around within weeks by producers who had better things to do at 21:40. The reason code asked a producer who cut a declared quantity to pick from a list: weather, pest, labour, sold elsewhere. In practice the top option in the list got picked every time, which made the field worse than useless because it looked like data. The lesson is that any field which is mandatory but not load-bearing will be satisfied with the cheapest possible answer. If you want to know why a number moved, ask the administrator to make one phone call to the three producers whose numbers moved most, and log that instead. The mid-week prompt asked producers to re-confirm on Wednesday whether Tuesday's number still held. It was ignored by most, and the ones who did engage tended to nudge numbers up and down in ways that destabilised baskets already committed by shoppers. It was replaced by an asymmetric rule: a producer can increase a declaration at any time before window close, but reducing one after shoppers have committed against it opens a shortfall record that the administrator sees immediately. Upward movement is free, downward movement is visible. ### Declared, committed, delivered: what the administrator sees when the three diverge Three numbers exist for every line in a delivery week. Declared is what the producer promised. Committed is what shoppers actually bought against that promise. Delivered is what arrived at pack-down. The administrator's job is not to make them equal, it is to notice which pair diverged and act on the right one. Declared far above committed is a demand problem, not a producer problem. Somebody is growing chard nobody is buying, and the fix is catalogue placement, price, or a conversation about switching a bed. Committed equal to declared on a line that sells out early is a supply signal worth acting on, because the producer capped themselves below demand and does not know it. Delivered below committed is the only one that hurts a shopper directly, and it is the only divergence that should generate an immediate alert rather than a weekly summary. The practical view is a single table per window with the three columns side by side and a fourth showing the gap between committed and delivered as a percentage. Sorted by that gap, the top few rows are the entire week's phone-call list. Everything below the line is fine, and an administrator who is not drowning in a hundred green rows is an administrator who actually makes those calls. ### Designing the ritual, not just the screen The mechanism that makes weekly declaration work is not the form, it is the fixed rhythm around it. One recurring evening, one reminder, one cut-off, in the same shape every week. Producers who declare on a schedule they can predict do it in minutes. Producers asked to declare whenever suits them do it late or not at all. Late declarers are a permanent minority in any co-op, and they are best handled by design rather than nagging. The carry-over rule already gives them a defensible default, so a late producer with an unchanged product mix loses nothing by confirming an hour before cut-off. The stale-declaration expiry protects shoppers from the ones who never confirm at all. Between those two rules, chasing individual producers becomes an exception rather than a weekly ritual for the administrator. The wider point for anyone building or choosing software for a short food supply chain: stock control for small growers is not a warehouse problem with fewer shelves. It is a promise-tracking problem with a weekly clock. Plodie's producer app is built around that, with the declaration, the shared-line caps and the pack-down acknowledgement all sitting on the same data model the administrator, shopper and delivery apps read from, which is what lets the three numbers be compared at all. ### Key Takeaways - Growers who harvest to order cannot maintain a running inventory count. Ask for a declared quantity against a fixed delivery window instead. - Pre-filling last week's lines is what makes a weekly declaration take minutes rather than an evening of data entry. - Six rules keep declared numbers honest: rolling carry-over, per-line caps on shared lines, stale-declaration expiry, partial-commit acknowledgement, under-delivery reconciliation, and hidden-not-zero as the no-declaration default. - A blank declaration must hide the line, never show it as available or sold out at a live price. - Track declared, committed and delivered as three separate numbers. Only the gap between committed and delivered should trigger an immediate alert. If the producers in question are new to smartphones entirely, the declaration ritual sits on top of a different set of interface decisions, covered in our [guide to onboarding growers who have never used an app](https://plodie.com/posts/onboarding-a-62-year-old-grower-who-has-never-used-an-app-designing-software-for). ### Frequently Asked Questions #### How do small farms track stock and availability without an inventory system? Most small farms that harvest to order do not track stock as a count at all. They declare a quantity they are willing to deliver into a specific delivery window, which is a commitment rather than a measurement. The platform then tracks how much of that declared quantity has been sold and how much actually arrives, which gives the same operational control as inventory without asking a grower to count things still growing. #### What happens when two producers supply the same product in a co-op catalogue? The catalogue shows one line, but the available quantity is the sum of each producer's declared quantity, with a per-producer cap applied when orders are allocated. That prevents one producer's number from absorbing all demand for the line. At pack-down the split is already decided, so each producer sees only their own allocation and the payout splits correctly. #### Should a producer with no stock this week set the quantity to zero or leave it blank? They mean different things and both should be supported. Zero is an explicit declaration of no availability this week, which is useful signal for the administrator. Blank means no declaration was made, and the safest behaviour is to hide the line from the shopper catalogue entirely rather than displaying it as sold out at a live price. #### How often should producers update availability in a food co-op? Once per delivery cycle, on a fixed recurring evening, is enough for most co-ops. More frequent updates destabilise baskets that shoppers have already committed to and create work without improving accuracy. The useful exception is allowing upward revisions at any time before the ordering window closes, since adding stock never breaks an existing order. #### What is an acceptable gap between what a producer declares and what they deliver? There is no universal figure, but the number worth watching is the gap between committed and delivered, not declared and delivered, because only the former affects a shopper's box. Set a threshold your operation can absorb through substitutions, review the lines that exceed it each week, and use repeat shortfalls to lower the default declared quantity the app suggests next cycle. ### Sources - [mitsloan.mit.edu](https://mitsloan.mit.edu/ideas-made-to-matter/supply-chain-transparency-explained) - [jaspero.co](https://jaspero.co/case-studies/plodovi) - [plodovi.com](https://plodovi.com/faq) - [omneelab.com](https://omneelab.com/managing-perishable-inventory/) - [quickbooks.intuit.com](https://quickbooks.intuit.com/ca/resources/inventory/what-is-perishable-inventory-management/) --- ## The Food Miles Report a Co-op Can Actually Produce: Turning Routes, Producer Locations and Order Lines Into a Defensible Sustainability Statement URL: https://plodie.com/posts/the-food-miles-report-a-co-op-can-actually-produce-turning-delivery-routes-produ Published: 2026-09-04 · Category: Business · By: Ivan Lauc Most ESG guidance is written for industrial supply chains. This is how a food co-op turns the data it already holds, producer coordinates, route distances and order lines, into a food miles, local spend and waste report it can defend. ### Why generic ESG tools cannot produce a food co-op's impact numbers Generic ESG platforms are built to collect supplier questionnaires and apply industry-average emissions factors to spend categories. A co-op does not need averages. It already holds the exact producer address, the exact route the van drove and the exact kilograms on each order line, which are the primary data most ESG software spends money trying to estimate. The mismatch shows up immediately. A spend-based ESG tool asked to assess a co-op would take the €4,200 paid to vegetable growers last month, multiply it by a national emissions factor for 'agricultural products', and return a number that is identical whether those vegetables came from 12 km away or 1,200 km away. That is precisely the distinction a short food supply chain exists to make, and it is the one the tool erases. The other problem is scope. Frameworks like the GHG Protocol treat purchased goods and upstream transport as Scope 3, the category most organisations report as an estimate because they cannot see into their suppliers' operations. A co-op can see into them. The producer is on the platform, the pickup point is a coordinate, and the delivery leg is a recorded route. A co-op's Scope 3 transport data is closer to primary measurement than most large retailers will ever get. ### What data a co-op already holds that can be turned into a report Five data sources are usually enough: producer locations, order lines with weights, route records, hub throughput, and pack-down waste logs. Everything in a credible food miles and local impact report is derived from those, and most co-ops are already capturing four of the five without realising it is reportable. The gap is almost always weight. Order lines are frequently stored in units the co-op sells in, bunches, punnets, heads, jars, and a food miles figure needs mass. The fix is a one-time exercise: add an average kilogram value to each product record. A bunch of chard is 0.25 kg, a jar of honey is 0.45 kg net plus 0.2 kg of glass. It takes an afternoon for a 300-line catalogue and it converts the entire order history into something measurable, retroactively. The second gap is the producer's own inbound leg. If a grower drives to a drop-off point, that distance belongs in the report and the co-op's system rarely knows it. Ask producers once, at onboarding, for the distance from their holding to the hub and how they usually get there. One field, filled in once, closes the largest hole in the calculation. - Producer records: holding address or coordinates, and self-reported distance to the hub - Product records: an average net weight per selling unit, plus packaging weight where relevant - Order lines: product, quantity, producer, delivery date, destination postcode - Route records: stop sequence, actual or planned distance, vehicle type and fuel - Pack-down logs: unsold, damaged and redistributed items by weight and reason ### How to calculate food miles without overclaiming Calculate weighted average food miles as the sum of (kilograms x kilometres) for every order line, divided by total kilograms delivered. Report it in tonne-kilometres per delivery leg, state whether it covers the inbound producer leg, the hub, or both, and never compare it to a supermarket figure you did not calculate yourself. Work in three legs and keep them separate in the output. Leg one is producer to hub. Leg two is hub to customer, which the routing data gives you directly. Leg three, customer to home, applies to pickup points and is usually excluded, but say so rather than silently dropping it. A report that shows 14 km inbound, 9 km outbound and an excluded final leg is more credible than a single unexplained '23 food miles' claim. The trap is comparison. Food miles are a distance metric, not a carbon metric, and a full-load lorry from 500 km away can carry a lower per-kilogram footprint than a half-empty van doing a 40 km loop. If you want a carbon figure, apply a published emissions factor for your vehicle class to the tonne-kilometre total and cite the factor and its year. If you only want to state distance, call it distance. Both are defensible. Blending them is not. - Total tonne-kilometres = sum of (line weight in tonnes x leg distance in km) - Weighted average food miles = total tonne-km / total tonnes delivered - Load efficiency = tonnes carried / vehicle capacity, reported per route - Optional carbon estimate = tonne-km x a cited emissions factor for the vehicle and fuel ### The two metrics that matter more than distance: local spend and waste avoided Local economic retention and diverted waste are usually the strongest numbers a co-op has, and both come from data it already reconciles. Local spend is the share of shopper payments that reaches producers within a defined radius. Waste avoided is the weight of food that reached a person instead of a bin at pack-down. Local spend is calculated from the settlement run, not from turnover. Take the total paid out to producers in the period, split it by the distance band of each producer's holding, and express it as a percentage of gross shopper spend. A co-op that pays out 68 cents of every euro to producers within 50 km can say that, and can show the payout ledger behind it. That figure is far more meaningful to a council or a rural development fund than a carbon estimate, because it maps directly onto the reason public money supports short supply chains. Multiplier claims are a separate matter: unless you have commissioned local economic research, report the retained spend and let others apply multipliers to it. Waste needs a discipline the co-op may not have yet: weighing at pack-down and recording a reason code. Unsold surplus, damage in transit, customer no-show, over-forecast. Once those exist, the report can state total kilograms handled, kilograms diverted to food banks or staff, kilograms composted and kilograms landfilled. It also stops being purely a reporting exercise, because the reason codes tell you which producers are over-supplying and which routes are damaging stock. ### Writing the statement so it survives scrutiny A defensible sustainability statement has four parts: the number, the boundary, the method and the data source. Omit any one of them and an assessor is entitled to discount the whole claim. The goal is not the most impressive figure, it is a figure someone else could reproduce from your records. State the boundary in plain language. Which period, which producers, which delivery legs, what is excluded and why. If 6 of your 38 producers never returned a distance figure, say that their volume was excluded and give the percentage of tonnage that represents. If you estimated packaging weight rather than weighing it, say estimated. Named limitations make the rest of the report more believable, not less. Then keep it comparable over time. Freeze the method for at least a year, version it, and when you change something, restate the prior period on the new basis. A co-op that reports 11.4 weighted average food miles in year one and 9.8 in year two, on a stated and unchanged method, has told a real story. One that changes its distance definition between reports has told nothing at all. - Number: the metric, its unit and the reporting period - Boundary: producers, legs and product categories included and excluded - Method: the formula, any emissions factor used, and its published source and year - Source: which system the underlying records came from and whether they are measured or estimated - Limitations: missing data, estimates and the share of volume they affect ### Turning the report into an operating habit, not an annual scramble Impact reporting only stays accurate if the inputs are captured during normal work rather than reconstructed at year end. That means the producer distance field is mandatory at onboarding, product weights are required before a line goes live in the catalogue, and pack-down weighing is part of closing the hub, not an extra task. The payoff is that the same fields serve two purposes. Load efficiency per route is a sustainability metric and a cost metric. Waste reason codes feed a food loss figure and a producer forecasting conversation. Producer distance bands support a local spend claim and a decision about which new grower to recruit for a thin category. None of this is separate ESG overhead if it is wired into the operational data model from the start. This is where a platform that already holds producer locations, routes, order lines and pack-down records has an advantage over a bolt-on reporting tool. Plodie captures those records because the co-op needs them to run deliveries and pay producers, which means the sustainability report is an aggregation of operational truth rather than a separate exercise in estimation. ### Key Takeaways - A co-op holds primary data, exact producer locations, route distances and order weights, that large ESG tools can only estimate with spend-based averages. - Weighted average food miles = total tonne-kilometres divided by total tonnes delivered, reported leg by leg with the boundary stated. - Food miles are a distance metric, not a carbon metric. Apply a cited emissions factor if you want carbon, and never blend the two. - Local spend retention from the payout ledger and weighed pack-down waste are usually more persuasive to funders and councils than a carbon estimate. - A claim survives scrutiny only when the number is published alongside its boundary, method, data source and named limitations, and the method stays frozen year to year. Many of these inputs overlap with the operational view we set out in [9 metrics a short food supply chain administrator should track](https://plodie.com/posts/the-co-op-dashboard-nobody-builds-9-metrics-a-short-food-supply-chain-administra), several of which feed straight into the impact report described here. ### Frequently Asked Questions #### Are food miles actually a good measure of environmental impact? On their own, no. Transport is often a small share of a food product's total footprint compared with production method, heating for greenhouse crops and refrigeration, and a full lorry can beat a half-empty van per kilogram. Food miles are still worth reporting as a transparent distance metric and as an input to load efficiency, but present them as distance rather than as a carbon claim. #### How do I calculate food miles if some producers won't give me their location? Exclude their volume from the calculation and state the exclusion as a percentage of total tonnage in the report. Do not substitute a guessed distance or a regional average, because that turns a measured figure into an estimated one without flagging it. In practice, making the distance field mandatory at producer onboarding closes the gap within one recruitment cycle. #### What emissions factor should a small food hub use for its delivery van? Use a published government or recognised national factor for your vehicle class, fuel type and load state, and cite the publication and its year in the report. Many countries publish annual conversion factors for freight and light commercial vehicles. Recalculate when the factor is updated, and restate prior periods if you want the trend to remain comparable. #### Does a small co-op legally have to report sustainability metrics? Most small co-ops and food hubs fall below mandatory sustainability reporting thresholds such as those in the EU's corporate sustainability rules. The pressure usually comes instead from grant applications, public procurement tenders, local authority partnerships and retail or restaurant buyers with their own Scope 3 targets. Voluntary reporting done well is often what wins those contracts. #### How is a local economic multiplier different from local spend retention? Local spend retention is what you can measure directly: the share of shopper payments that reaches producers inside a defined radius, taken from your payout ledger. A local economic multiplier estimates how many times that money recirculates in the area and requires separate economic research to establish. Report the retention figure as fact and treat any multiplier as a cited external estimate. ### Sources - [pmc.ncbi.nlm.nih.gov](https://pmc.ncbi.nlm.nih.gov/articles/PMC11507108/) - [dr.lib.iastate.edu](https://dr.lib.iastate.edu/server/api/core/bitstreams/525cb2fb-f163-46d3-895c-f3a92f600088/content) - [content.ces.ncsu.edu](https://content.ces.ncsu.edu/local-food-systems-clarifying-current-research) - [canr.msu.edu](https://www.canr.msu.edu/foodsystems/uploads/files/Webinar_MSU_12.14.2015.pdf) - [en.wikipedia.org](https://en.wikipedia.org/wiki/Food_miles) --- ## The Co-op That Wouldn't Log In: A Change Management Playbook for 38 Producers, 4 Admins and 6 Drivers URL: https://plodie.com/posts/the-co-op-that-wouldn-t-log-in-a-change-management-playbook-for-getting-38-produ Published: 2026-09-03 · Category: Product · By: Ivan Lauc Digital transformation in a food co-op fails on people, not software. A role-by-role change management playbook for rolling out one platform across producers, administrators and drivers, including who resists, what breaks trust and the training order that sticks. ### Why co-op software rollouts fail on people, not features Most co-op software rollouts fail because the platform changes who holds information and who can be blamed when something goes wrong. Producers lose the ability to phone a friendly administrator and negotiate. Administrators lose the informal control that came from owning the spreadsheet. Nobody says this out loud, so it surfaces as 'the app is confusing'. In a spreadsheet-run co-op, a lot of value sits in one person's head. That administrator knows Marija always underreports her lettuce by 10% so she has slack, knows the driver on the northern route will not take the last stop after 4pm, knows which producer to call when someone drops out on Thursday. A platform makes all of that explicit, and explicit means auditable. The producer who used to have quiet flexibility now has an on-time rate visible to an administrator. That is not a reason to avoid the platform. It is a reason to name the shift openly during the rollout rather than pretending the software is neutral. When we introduce a system, the honest framing is: this makes the co-op's operations legible to everyone in it, including you, and the first people to benefit are the ones being blamed for problems they did not cause. ### Who actually resists, and what each objection really means Resistance is rarely uniform. In a co-op of 38 producers, 4 administrators and 6 drivers, opposition clusters into four recognisable patterns, and each needs a different response. Treating all of them as a training problem is the fastest way to lose the group that is not resisting training at all. The most dangerous objection is not the loud one. A producer who says 'I'm too old for this' will usually be posting stock within two weeks if the interface is simple enough. The administrator who quietly keeps a parallel spreadsheet 'just in case' is the one who will still be running it in month six, and every other person in the co-op will notice that the real numbers live somewhere else. - The low-confidence producer: says 'I don't understand computers'. Actually means 'I am afraid of making a public mistake in front of the co-op'. Fix: private practice mode, undo everywhere, no notification to others when they edit. - The status-loss administrator: says 'the system doesn't handle our exceptions'. Actually means 'my expertise was the exception handling'. Fix: put them in charge of configuring the exception rules, so their knowledge becomes the system's knowledge. - The high-volume producer: says 'I already have my own system'. Actually means 'you are asking me to do double entry for the co-op's benefit'. Fix: CSV import or integration before you ask them to type anything. - The driver: says almost nothing, then keeps using paper. Actually means 'the app needs two hands and a signal, and I have neither at the kerb'. Fix: offline-first, one-thumb confirmations, and let them see the route before they leave the depot. ### The training sequence that sticks: drivers, then admins, then producers Train in the order of blast radius, smallest first. Drivers are 6 people doing one repetitive task and give you clean feedback within a day. Administrators are 4 people who become internal support. Producers are 38 people you can only train once before word of mouth decides the outcome, so they go last. The instinct is to start with producers because there are most of them and they are the hardest. That is backwards. Producers judge the platform by whether their first week goes smoothly, and their first week goes smoothly only if the administrators already know the answers and the drivers are already confirming deliveries correctly. Train producers first and every early question lands on an administrator who is also learning, which produces the sentence that kills a rollout: 'nobody knows how this thing works'. Producer training itself should be staged, not blanket. Start with 5 or 6 producers who are already comfortable with a smartphone and are respected in the group, run one real order cycle with them, then let them be the reference point. The remaining producers are far more receptive to 'Ivan did it last week and got paid on time' than to a training deck. - Week 1: Drivers. One route, one van, real stops. Fix whatever fails at the kerb before anyone else sees the system. - Week 2: Administrators. Full order cycle in a sandbox, then configure the exception rules with them, not for them. - Week 3: Pilot producers. 5 to 6 volunteers post real stock for one real order window while the spreadsheet still runs in parallel. - Weeks 4 to 6: Remaining producers, in cohorts of 8 to 10, each cohort supported by a pilot producer rather than by the vendor. - Week 7: Cut the parallel spreadsheet. Announce the date two weeks in advance and do not move it. ### What breaks trust in the first 30 days, and how to prevent it Trust in a co-op platform is lost by money errors, phantom orders and silent failures, not by ugly interfaces. A producer who is paid the wrong amount once will check every payout manually for a year. A driver whose confirmed delivery does not appear in the admin view stops confirming deliveries. Both failures are recoverable technically and expensive socially. The prevention is unglamorous. Run the first two settlement cycles against the old spreadsheet line by line and show producers both numbers side by side, including the cases where the platform is right and the spreadsheet was wrong. Make every state change visible to the person who caused it: if a producer edits available stock, they should see the new number reflected in the shop within the same session, not on a delayed sync. If an action fails, say so immediately in plain language rather than failing quietly and reconciling later. One more thing matters more than it should: response time to questions in the first month. A producer who messages an administrator on Tuesday about a stock discrepancy and hears nothing until Friday concludes the system is unsupported. Set an explicit internal target, name a single person per week as the answer point, and publish who it is. ### Measuring adoption honestly: the metrics that tell you it worked Login counts are a vanity metric. Real adoption shows up as a reduction in the workarounds: fewer phone-call orders, fewer manual spreadsheet corrections before settlement, fewer paper delivery notes coming back in the van. Track the old channels going quiet, not the new one lighting up. Four numbers are worth reviewing weekly during the first quarter. First, the share of producers who posted stock without a reminder, which tells you whether the habit formed or whether administrators are still chasing. Second, the number of orders created by an administrator on a producer's behalf, which should trend towards zero. Third, the count of deliveries confirmed in the app versus deliveries confirmed by phone. Fourth, settlement corrections after the run, which is the single best proxy for whether people trust the numbers. Expect a dip. Somewhere around week 5 or 6, usually right after the parallel spreadsheet is cut, throughput drops and complaints spike. That is not failure, it is the point where the last workarounds die. The rollouts that fail are the ones where leadership reinstates the spreadsheet during that dip, because after that nobody believes the cutover date again. ### Governance after go-live: who owns the platform inside the co-op A platform without a named internal owner degrades within a season. Assign one administrator as the system owner with explicit authority over price list changes, new producer onboarding and exception rules, and give them a standing slot in the co-op's regular meeting. Vendor support handles bugs; the co-op handles decisions. The decisions that need an owner are mundane and constant. What happens when a producer lists a product that overlaps with another producer's? Who approves a new delivery zone? What is the cut-off for editing stock before the order window closes, and who can override it? If these are decided ad hoc by whoever is on the phone, the platform slowly turns back into a spreadsheet with extra steps. It also helps to schedule a review at the end of the first full season, with producers in the room. Ask what they still do outside the system and why. The answers point at genuine product gaps, and the act of asking is itself part of change management: it signals that the platform belongs to the co-op rather than being something done to it. That feedback loop is how Plodie's producer, administrator and driver apps have been shaped, largely by running our own short food supply chain and watching where people quietly went back to paper. ### Key Takeaways - Resistance to co-op software is usually about lost informal control and fear of public mistakes, not about the interface. - Train in order of blast radius: 6 drivers first, then 4 administrators, then producers in small cohorts led by respected early adopters. - Trust is broken by payout errors and silent failures, so reconcile the first two settlement runs line by line against the old spreadsheet. - Measure adoption by the old channels going quiet: fewer phone orders, fewer admin-entered orders, fewer settlement corrections. - Expect an adoption dip right after the parallel spreadsheet is cut, and do not reinstate it. This playbook covers the people side of the switch; the technical side is laid out in our [6-week migration plan](https://plodie.com/posts/from-spreadsheets-to-software-the-6-week-migration-plan-we-use-to-move-a-food-co), which maps order sheets, price lists and delivery routes into the platform week by week. ### Frequently Asked Questions #### How long does it take a food co-op to fully switch from spreadsheets to a platform? Plan for six to eight weeks of rollout plus one full season of settling. The technical migration of order sheets, price lists and routes can be done in a few weeks, but habit change across dozens of producers takes at least three or four complete order cycles. Cutting the parallel spreadsheet around week 7 forces the transition; keeping it longer indefinitely delays adoption. #### What do you do about a producer who simply refuses to use the app? First check whether it is refusal or an access problem, since poor signal, a shared family phone or a cracked screen look identical to refusal from the admin side. For genuine holdouts, keep a supported fallback such as an administrator entering their stock from a weekly phone call, but make the cost visible: they get later order windows and no real-time stock edits. Most convert once they see peers getting paid faster. #### Should the co-op run the old spreadsheet in parallel with the new platform? Yes, but only for a fixed and announced period, typically three to four weeks covering the pilot and first cohorts. Parallel running lets you reconcile settlement numbers and catch mapping errors before money moves. Open-ended parallel running is the most common cause of stalled adoption, because staff default to the tool they already trust. #### Who should lead a digital transformation project inside a small food co-operative? An internal administrator with operational credibility, not the most technical person and not an external consultant. They need authority over price lists, onboarding and exception rules, plus a standing agenda slot at co-op meetings. The vendor handles bugs and feature requests; decisions about how the co-op runs must stay inside the co-op. #### How do you train producers with low digital literacy without a manual? Train on their own phone, with their own real products, during a real order window rather than in a demo environment. Cover one task only, posting available stock, and let everything else wait until that task is habitual. A peer producer who completed the same step last week is a more effective trainer than a vendor representative. ### Sources - [pearl.plymouth.ac.uk](https://pearl.plymouth.ac.uk/cgi/viewcontent.cgi?article=1711&context=pbs-research) - [meegle.com](https://www.meegle.com/en_us/topics/digital-transformation/digital-transformation-in-rural-areas) - [en.nhandan.vn](https://en.nhandan.vn/digital-transformation-in-agriculture-paving-the-way-for-cooperatives-to-adapt-to-digital-future-post154747.html) - [jaspero.co](https://jaspero.co/case-studies/plodovi) - [prosci.com](https://www.prosci.com/blog/technology-transformation) --- ## Who Owns the Data in a Food Co-op? Access Rules, Roles and GDPR Across Four Apps and 40 Producers URL: https://plodie.com/posts/who-owns-the-data-in-a-food-co-op-data-governance-access-rules-and-gdpr-across-f Published: 2026-09-02 · Category: Product · By: Ivan Lauc A practical guide to data governance in a short food supply chain: who controls shopper purchase history, what a driver can see of an address, what one producer can never see of another, and how GDPR roles map onto a 40-producer co-op. ### Who actually owns shopper data in a food co-op? The co-operative, as the legal entity running the storefront, is the data controller for shopper accounts and order history. Producers and drivers see only the slices they need to fulfil an order. Under GDPR the shopper does not "own" the data in a property sense, but holds rights over it: access, correction, portability and erasure. This matters because co-ops are usually member-owned, and members reasonably assume that anything the co-op holds is collectively theirs. It is not. If 40 producers are members of the co-operative, that does not give any one of them a right to browse the customer list. The co-op decides why and how personal data is processed, so the co-op carries the obligations and the liability, and the platform vendor processes that data on the co-op's written instructions. The practical test is simple. Ask who would receive the complaint if a shopper's address leaked. It would be the co-operative, not the grower who packed the carrots and not the software vendor. That answer tells you where governance has to live: in the co-op's own policies, enforced by the platform's permission model rather than by trust and good intentions. - Co-operative: data controller for shopper accounts, orders, payments and delivery records - Platform vendor: data processor, acting on documented instructions under a data processing agreement - Producer: sees order lines for their own goods, plus whatever the co-op explicitly discloses - Driver: sees delivery-window details for stops on the assigned route, nothing before or after - Shopper: data subject, with rights of access, rectification, portability, objection and erasure ### What can a producer see, and what must stay hidden? A producer should see everything about their own goods and money, and nothing about anyone else's. That means their own order lines, stock movements, unit prices, commission deductions and payout statements. It excludes another producer's volumes, margins or payouts, and it usually excludes shopper names and addresses entirely. Producer-to-producer confidentiality is the rule co-ops most often get wrong, because early on everyone works from one shared spreadsheet and nobody minds. At 40 producers it stops being harmless. A grower who can see that a neighbour sold three times as many courgettes at a better unit price will either undercut them or leave. Aggregate views are fine and useful, such as total co-op sales this month or category-level demand, as long as they cannot be reverse-engineered into a single competitor's figures. If only two producers sell honey, a "honey category total" is not anonymous. Shopper identity is the second boundary. A producer packing 14 boxes needs a pick list with quantities and box identifiers, not 14 names and street addresses. Some co-ops choose to include a first name on a note card for a personal touch, which is a legitimate choice, but it should be a documented decision with a stated purpose, not an accident of how the pick list was built. ### What should a delivery driver see about a customer? A driver needs the delivery address, a contact name, a phone number for the last 200 metres, access notes such as a gate code or buzzer, and the box identifiers for that stop. They should not see order contents, prices, payment details, past orders or any address outside their assigned route, and access should expire once the route closes. Driver access is time-boxed rather than permanent, and that distinction does what a privacy policy alone cannot. A driver who left the co-op six months ago should not be able to open the app and pull up a street's worth of addresses. Route-scoped, day-scoped visibility keeps exposure proportionate to the job. The awkward cases are worth deciding in advance rather than in the van. What happens when a driver takes a photo as proof of delivery and the photo includes a house number, or a child, or an open doorway? What happens when a customer asks the driver to leave the box with a neighbour, creating a record of an address the co-op never collected? Write the rule down: proof-of-delivery photos show the box and the doorstep only, are retained for a defined window tied to dispute resolution, and are deleted after it. ### How do the four roles map onto GDPR controller and processor duties? The co-operative is the controller. The software vendor is a processor bound by a data processing agreement. Producers and drivers are usually acting within the controller's organisation rather than as separate controllers, but a producer who takes a shopper's contact details for their own direct marketing becomes an independent controller for that new purpose and needs their own legal basis. Getting the lawful basis right for each processing purpose keeps the rest of the governance simple. Fulfilling an order runs on contract necessity, because you cannot deliver a box without an address. Invoicing and food safety records run on legal obligation, which is also what justifies keeping traceability data after a shopper deletes their account. Newsletters and marketing run on consent, which is separate, revocable and must not be bundled into checkout. Fraud checks and platform security typically run on legitimate interest, documented in a balancing assessment. The distinction becomes concrete during an erasure request. A shopper asking to be forgotten does not erase the invoice a co-op is legally required to keep, nor the batch record linking a crate of lettuce to a grower. What gets deleted is the account, the contact details, the marketing profile and the delivery notes. What survives, in pseudonymised or legally-mandated form, is the accounting and traceability trail. Say this in your privacy notice before anyone has to ask. ### Building the access matrix: a practical governance checklist for a co-op Write down, field by field, which of the four roles can read it, write it and export it. That single table is the backbone of your governance, because it turns vague promises into something you can configure, audit and hand to a member who asks what the co-op knows about them. The exercise takes an afternoon and surfaces disagreements that would otherwise appear during a dispute. Most co-ops discover two or three fields where nobody agrees, typically shopper phone numbers, producer unit prices and delivery photos. Settle those in a members' meeting and record the decision. Then check that the platform can actually enforce it, because a governance policy that relies on people not clicking the wrong export button is not a control. Retention is the other half. Decide how long each category lives: order and delivery records for the period your accounting rules require, traceability records for the shelf-life-plus-margin window your food safety regime requires, marketing consents until withdrawn, driver location data for days rather than years. Then run one deletion job on a schedule rather than promising to tidy up later. - List every data field the platform holds, grouped by shopper, producer, order, delivery and payment - Assign read, write and export permissions per role for each field, and note the lawful basis - Define retention periods per category, plus what survives an erasure request and why - Sign a data processing agreement with the platform vendor, and list any sub-processors such as payment or mapping providers - Decide the breach procedure: who is notified, who assesses, and who files with the supervisory authority within 72 hours - Review the matrix annually and whenever a new role, integration or export feature is added ### Where governance breaks in practice, and how software prevents it Most co-op data incidents are not hacks. They are spreadsheet exports emailed to a producer, a shared admin login used by four volunteers, a WhatsApp group with customer phone numbers in it, and an ex-driver whose account was never disabled. Role-based accounts, scoped views and audit logs remove the need for those workarounds. The pattern is consistent: people export data because the system will not show them what they need in the shape they need it. A producer asks for the customer list because they want to know which villages to grow for, when what they actually need is an anonymised demand-by-postcode view. An administrator mails a spreadsheet because generating a per-producer payout statement is easier in Excel than in the tool. Fix the underlying view and the risky export stops happening on its own. An audit trail closes the loop. Knowing who viewed which shopper record, who changed a price, and who exported what, with timestamps, converts an argument into a lookup. That is also the evidence a supervisory authority will ask for if something goes wrong. Plodie's four-role architecture is built around exactly these boundaries, with administrators, shoppers, producers and drivers each working from the same underlying data model but seeing only the fields their job requires. ### Key Takeaways - The co-operative is the GDPR data controller for shopper data; the platform vendor is a processor, and producers and drivers only see scoped slices of it. - Producer-to-producer confidentiality is the boundary co-ops break first: nobody should see another grower's volumes, prices or payouts. - Driver access should be route-scoped and time-boxed, covering address, contact and access notes, never order contents or payment data. - Erasure requests delete accounts and contact details, but accounting and food traceability records survive under legal obligation. Say so in the privacy notice. - Build a field-by-field access matrix with retention periods, then enforce it in software rather than through trust and manual restraint. For the interface side of these same role boundaries, see [how we design four apps that feel like one](https://plodie.com/posts/designing-four-apps-that-feel-like-one-ux-decisions-behind-a-multi-role-short-fo), covering the shared data model behind the administrator, shopper, producer and delivery views. ### Frequently Asked Questions #### Does a small food co-op really need a GDPR data processing agreement with its software provider? Yes. If a vendor stores or handles personal data on your behalf, GDPR requires a written processing agreement regardless of how small the co-op is. There is no volume threshold that exempts you. The agreement should name sub-processors such as payment gateways, mapping services and email providers, and state where data is hosted. #### Can producers in a co-op contact customers directly to sell to them? Only if the customer has given consent for that specific purpose, and the producer then becomes an independent data controller with their own obligations. Passing a co-op customer list to a producer for direct marketing without consent is a common and serious breach. A safer route is co-op-branded messaging where shoppers opt in to hear from named producers. #### What happens to co-op data if a producer leaves or the platform contract ends? Producers should be able to export their own product, order and payout history in a machine-readable format, and their access to co-op data should be revoked on the leaving date. On contract exit, the processing agreement should oblige the vendor to return or delete all personal data within an agreed window and to confirm deletion in writing. #### Do we need a Data Protection Officer for a 40-producer food co-op? Usually no. A DPO is mandatory only for public authorities or organisations whose core activity involves large-scale systematic monitoring or large-scale processing of special category data. A typical local food co-op meets none of those tests, but you should still name one person as the accountable point of contact for data requests and breaches. #### How long should a food co-op keep delivery photos and driver location data? Keep proof-of-delivery photos only as long as your dispute window requires, commonly a few weeks to a couple of months, then delete them automatically. Driver location data used for live routing should be measured in days, not years. Anything retained longer needs a documented purpose, because "it might be useful" is not a lawful basis. ### Sources - [pmc.ncbi.nlm.nih.gov](https://pmc.ncbi.nlm.nih.gov/articles/PMC12191791/) - [commission.europa.eu](https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/principles-gdpr_en) - [dataprotection.ie](https://www.dataprotection.ie/en/dpc-guidance/data-sharing-in-the-public-sector) - [accountablehq.com](https://www.accountablehq.com/post/what-is-a-data-controller-a-beginner-s-guide-to-gdpr-roles-duties-and-examples) - [trustarc.com](https://trustarc.com/resource/data-minimization-gdpr-ccpa-privacy-laws/) --- ## GDPR in a Food Co-op: Who Owns the Producer's Sales Data, the Shopper's Address and the Driver's Location Trail URL: https://plodie.com/posts/gdpr-in-a-food-co-op-who-owns-the-producer-s-sales-data-the-shopper-s-address-an Published: 2026-08-31 · Category: Product · By: Ivan Lauc A practical guide to data governance in a short food supply chain: who is controller and processor, what a producer may see about shoppers, how long to keep delivery location trails, and where aggregated demand data crosses an ethical line. ### Who is the controller and who is the processor in a food co-op? In almost every short food supply chain, the co-operative or food hub is the data controller for shoppers, and the software platform is the processor acting on written instructions. Producers are usually neither: they are recipients of a narrow slice of co-op data, or separate controllers only for their own customer relationships. This matters because the roles decide who answers a subject access request, who notifies the regulator after a breach, and who signs what. If a shopper emails asking for a copy of their data, the co-op answers it. The platform's job is to make that answer producible in minutes rather than by exporting three spreadsheets and hoping nothing was missed. The co-op needs a data processing agreement with the platform under Article 28, and a much shorter, plainer agreement with each producer that spells out what producer users may see and what they may not do with it. The tricky case is the delivery driver. If the driver is co-op staff, they are simply an authorised user under the co-op's control. If the driver is a self-employed contractor or a third-party courier, they become a separate controller for their own business records and a recipient of shopper addresses for the duration of a route. That distinction changes the contract, not the software, but the software has to make the difference visible: contractor accounts should see less, and for less time. - Co-op as controller: shopper accounts, orders, addresses, payment references, complaints, delivery outcomes. - Platform as processor: hosting, backups, support access, subprocessors, breach notification to the co-op. - Producer as recipient: their own sales lines, their own stock, aggregate demand for their categories, delivery-relevant notes. - Producer as separate controller: only where they collect customer data themselves, for example on-farm sales or their own newsletter. ### What can a producer actually see about a shopper? A producer should see what they need to fulfil and get paid: quantities sold, product mix, timing, and settlement lines. They should not see shopper names, addresses, phone numbers or purchase histories across other producers. The lawful basis for showing more than that rarely exists, and the operational need almost never does. Producers ask for names for understandable reasons. They want to know who bought the goat cheese so they can thank them, upsell them, or invite them to the farm. In a co-op model the customer relationship belongs to the co-op, and the shopper agreed to buy from the co-op, not to be added to eleven separate farm mailing lists. The clean answer is to keep identity behind the co-op and offer producers what they actually need: unit-level sales, repeat-purchase rates in aggregate, and an opt-in channel where a shopper can choose to follow a specific producer. There are two exceptions worth designing for. First, direct pickup at the farm: if the shopper collects from the producer, the producer needs a name and an order reference to hand over the right box, and nothing else. Second, quality issues: when a complaint concerns a specific batch, the producer needs the batch and the problem, not the complainant's address. Both are solvable with field-level permissions rather than a blanket "producers can see orders" switch. ### Who owns the producer's sales data when they leave the co-op? Ownership is the wrong word legally, but the practical rule is simple and should be written down before anyone leaves: the producer can export their own sales history, price lists, product descriptions and photos at any time; the co-op keeps the transaction records it needs for accounting and food safety law; and neither party takes the shopper list. Departure is when unwritten assumptions turn into disputes. A grower who spent three seasons building a following expects to leave with something. A co-op that funded the storefront, the deliveries and the customer acquisition expects the customer base to stay. Both are partly right, which is why the exit clause needs to be in the producer agreement on day one, not negotiated in a bad mood on the way out. Spell out the export format, the notice period, and what happens to product photos the co-op paid a photographer to shoot. Retention runs on a different clock from goodwill. Invoices and settlement records are typically kept for the statutory accounting period in the relevant member state, often five to eleven years. Traceability records for batch and lot data follow food law, not GDPR minimisation, and cannot simply be deleted because a producer left. A shopper's erasure request does not erase the invoice; it erases the marketing profile, the saved address book and the account, while the financial record survives in a pseudonymised or legally required form. - Producer keeps: their sales lines, their catalogue content, their own uploaded media, their payout history. - Co-op keeps: invoices, settlement runs, VAT records, batch traceability, complaint logs. - Nobody takes: the shopper list, shopper addresses, or the co-op's aggregated demand data. - Written before onboarding: export format, notice period, media licensing, and who pays for the export. ### How long should you keep a driver's location trail? Keep raw GPS breadcrumbs for days, not years. A defensible pattern is high-resolution location for the length of the route plus a short dispute window of roughly 7 to 30 days, then reduce to the facts that matter: delivery timestamps, stop outcomes, and distance totals. Continuous tracking outside working hours has no lawful basis. Location data on a delivery app is genuinely useful. It answers "where is my box", it settles the argument about whether the van reached the address, and it makes route planning honest. It is also employee monitoring, which in most EU member states triggers additional national employment rules and, where applicable, works council or union consultation. Legitimate interest can support route-level tracking with a documented balancing test. It does not support keeping a year of second-by-second traces just because storage is cheap. The practical controls are unglamorous and effective: tracking starts when the driver begins a shift and stops when the shift ends, with a visible indicator in the app so the driver always knows the state. Proof-of-delivery photos should frame the doorstep, not the customer, and should expire on the same clock as the location trail. Aggregated route efficiency figures can persist indefinitely because they no longer identify anyone, which is exactly why they are the right thing to keep. ### Data minimisation in practice: what a co-op should stop collecting Most co-ops collect fields nobody uses. The fastest privacy win is a column audit: take every field in the shopper, producer and delivery records, name the person who reads it and the decision it drives, and delete the ones with no answer. Fewer fields means less to secure, less to export, and less to lose. Common offenders in local food operations include date of birth collected "for verification", full delivery instructions retained forever rather than per order, free-text notes fields that accumulate sensitive detail such as "leave at the back, resident has mobility problems", and phone numbers copied into a driver's personal messaging app where the co-op has no control at all. That last one is the most common informal breach in short food supply chains, and it happens because the software did not offer a masked call or in-app message. Special categories deserve particular care. Allergy and dietary information looks like a nice product feature and is health data under Article 9. If you collect it, collect it with explicit consent, keep it attached to the order rather than the profile where possible, and never expose it to a producer who only needs to know that a box excludes gluten. Similarly, a note that a shopper is a religious-holiday customer or a member of a charity food scheme can reveal beliefs or social status. If the operation does not need it to deliver food, it should not be in the database. - Audit each field: who reads it, which decision it drives, how long it needs to live. - Replace stored phone numbers in driver chats with in-app masked contact. - Attach delivery instructions to the order, not permanently to the shopper profile. - Treat allergy and dietary data as Article 9 health data with explicit consent and tight access. - Set a retention period per record type and enforce it automatically, not by an annual cleanup someone forgets. ### The ethical limits of aggregated demand data and AI features Aggregated demand data is the co-op's most valuable asset and its easiest ethical mistake. Anonymised category trends can fairly guide planting advice, route planning and range decisions. Using the same data to undercut a producer's price, to clone a top seller under a co-op label, or to score individual shoppers for pricing crosses from analytics into extraction. The reason to draw the line explicitly is that a co-op holds a structural information advantage. It sees all demand; each producer sees only their own sales. That asymmetry is fine when it is used to help the whole chain plan, and corrosive when it is used to bargain harder against the weakest party at the table. A short written policy helps: state which aggregates producers get to see for free, state that the co-op will not use producer-level margin data to source a competing supplier for the same product without telling the producer, and state what happens if the co-op ever launches its own label. AI features raise the same question with a new surface. Demand forecasting, box recommendations and automatic reordering are legitimate uses of historical data and mostly do not require personal data at all once aggregated. Individual profiling is different. Automated decisions that materially affect a person, such as refusing a delivery slot or applying different prices based on behavioural scoring, engage Article 22 and need human involvement plus an explanation. Under the EU AI Act, most co-op use cases sit in the minimal-risk band, but transparency obligations still apply when a shopper is talking to a chatbot rather than a person. The safe default is to build forecasting on anonymised aggregates, keep humans in charge of anything that affects an individual, and tell people plainly which is which. ### A one-page governance checklist for a co-op with four apps If you run admin, shopper, producer and delivery apps on one data model, governance means writing down, per role, what each app can read, what it can write, and how long the data lives. That single table is more useful than a long policy document, because it is the thing developers and administrators actually implement and audit. Build it in that order, then test it by trying to answer three questions with a stopwatch: can you produce everything you hold on one shopper in under an hour, can you delete an account without breaking the settlement history, and can you tell a producer exactly what the co-op sees that they do not. If any answer is no, the gap is in the data model, not in the paperwork. - A record of processing activities listing every category of data, purpose, lawful basis and retention period. - A data processing agreement with the platform, plus a current list of subprocessors and hosting locations. - A short producer data agreement covering visibility, export on exit, and use of catalogue content. - Role-based field-level permissions, with contractor drivers on a tighter profile than staff. - Automated retention jobs per record type, including location trails and proof-of-delivery photos. - A tested subject access and erasure procedure that preserves statutory invoice and traceability records. - A breach playbook with named roles, a 72-hour clock, and a template notification to the co-op's members. - A plain-language privacy notice a shopper can read in two minutes, published where they place the order. ### Key Takeaways - The co-op is the controller for shopper data, the platform is the processor, and producers are usually recipients of a narrow slice rather than joint controllers. - Producers need quantities, timing and settlement lines, not shopper names and addresses. Identity stays behind the co-op unless the shopper opts in or collects at the farm. - Write the exit rules before onboarding: producers export their own sales and catalogue, the co-op keeps invoices and traceability, nobody takes the shopper list. - Driver location trails should live for a short dispute window and then reduce to timestamps and distances. Tracking outside shift hours has no lawful basis. - Aggregated demand data is fair game for planning and unfair when used to undercut producers or price individual shoppers. Keep AI features on anonymised aggregates and humans on decisions that affect people. The permission boundaries described here are the same ones we work through when designing [four apps that feel like one](https://plodie.com/posts/designing-four-apps-that-feel-like-one-ux-decisions-behind-a-multi-role-short-fo), where admin, shopper, producer and delivery roles share a data model without sharing a view of it. ### Frequently Asked Questions #### Does a small food co-op really need a DPO under GDPR? Usually not. A designated data protection officer is mandatory only for public authorities, for large-scale systematic monitoring, or for large-scale processing of special category data. A co-op selling vegetable boxes to a few thousand households normally falls outside those triggers, but it still needs a named person accountable for privacy, a record of processing activities and a working response procedure. If you collect detailed allergy or health data at scale, reassess. #### Can a food co-op share shopper data with producers if the shopper agrees? Yes, if the consent is genuinely specific, freely given and separable from placing the order. That means a shopper can tick a box to follow a specific producer or receive their updates without losing access to the shop. Bundling producer data-sharing into the checkout terms is not valid consent, and consent has to be as easy to withdraw as it was to give. #### What should a co-op do in the first 24 hours after a data breach? Contain the access, record the time you became aware, and assess what data and how many people are affected. If there is a risk to individuals' rights and freedoms, notify the supervisory authority within 72 hours of becoming aware, even if the assessment is incomplete. If the risk is high, notify the affected shoppers directly in plain language, telling them what happened and what to do about it. #### Is WhatsApp acceptable for coordinating drivers and producers in a co-op? It is common and it is a governance problem. Shopper names, addresses and phone numbers pasted into a consumer messaging app leave the co-op's control, sit on personal devices, and cannot be deleted, exported or audited when someone makes a subject access request. If group chat is unavoidable, keep personal data out of it and move the actual delivery details into a system with roles, logs and retention rules. #### How long does a food co-op have to keep traceability records, and does erasure override that? Food traceability records follow food law rather than GDPR, and general EU rules point to keeping one-step-back, one-step-forward records for a period tied to the product's shelf life, with member state specifics on top. A shopper's erasure request does not delete those records or the statutory invoice. It removes the account, marketing profile and unnecessary personal detail while the legally required record stays, ideally pseudonymised. ### Sources - [pmc.ncbi.nlm.nih.gov](https://pmc.ncbi.nlm.nih.gov/articles/PMC6549023/) - [globeriadatenschutz.de](https://www.globeriadatenschutz.de/en/docs/how-must-website-treat-location-data-under-the-gdpr/) - [gov.uk](https://www.gov.uk/government/publications/data-ownership-in-government/data-ownership-model) - [dpo-consulting.com](https://www.dpo-consulting.com/blog/gdpr-data-governance) - [privacyengine.io](https://www.privacyengine.io/blog/gdpr-data-ownership/) --- ## Running a Local Food Hub on One Platform: How Aggregation, Consolidated Ordering and Multi-Producer Reconciliation Actually Work URL: https://plodie.com/posts/running-a-local-food-hub-on-one-platform-how-aggregation-consolidated-ordering-a Published: 2026-08-30 · Category: Product · By: Ivan Lauc A working breakdown of food hub operations on a single platform: how catalogue aggregation, consolidated ordering, pick-and-pack splits, route assignment and multi-producer reconciliation fit together instead of living in five disconnected tools. ### What a food hub actually does operationally, in five steps A food hub aggregates supply from many independent producers, sells it as one catalogue, splits each customer order back into per-producer pick lists, consolidates the picked goods into single deliveries, and then reconciles money in both directions. Those five steps are one workflow, not five departments. The complexity is not in any single step. It is in the fact that every step depends on data created in the previous one, and that data changes constantly. A grower revises availability on Tuesday morning after a frost. A customer edits an order on Tuesday afternoon. The pick list printed Tuesday evening has to reflect both. When each step lives in a different tool, someone has to carry the change across manually, and that person becomes the bottleneck and the source of most errors. Most hubs start with the tools that are free and familiar: a shared spreadsheet for availability, a form or email thread for orders, a storefront for retail customers, a messaging group for drivers, and a second spreadsheet for producer payments. Each works. The seams between them do not. - Aggregate: collect availability, prices and lead times from every producer for the coming order window - Publish: merge that into one shopper-facing catalogue with hub pricing, margin and delivery options applied - Order: take customer orders against live, shared stock so two customers cannot buy the same last five kilos - Split and consolidate: break orders into producer pick lists, then reassemble arriving goods into customer boxes - Reconcile: settle what each producer is owed, what the hub retained, what the delivery cost and what the customer paid ### Aggregation: turning forty availability lists into one catalogue Aggregation means each producer maintains their own products, prices, units and available quantities, and the platform composes those into a single shopper catalogue automatically. The hub sets margin rules, ordering windows and product approval, but does not retype anyone's list. Availability changes propagate to the storefront without an intermediate step. The hard parts are unit consistency and window discipline. One grower sells lettuce by the head, another by the kilo, a third by the case of twelve. A hub that lets these coexist untranslated will eventually pick 12 heads when the customer bought 12 cases. The fix is a shared unit vocabulary defined once at the hub level, with each producer's own unit mapped to it at product setup, so pick lists, invoices and payouts all speak the same language. Window discipline matters just as much. Producers need a cut-off after which stock is committed and cannot silently vanish, and a mechanism for declaring a shortfall that triggers a defined consequence: substitution, partial refund, or removal from the box. If shortfalls arrive as WhatsApp messages at 6am, no amount of catalogue software helps. The declaration has to happen in the same system that holds the order. ### Consolidated ordering: one basket, many suppliers, one checkout Consolidated ordering lets a customer fill one basket from several producers and check out once, with a single payment, one delivery slot and one order reference. Behind that single order, the platform holds per-producer line items so the same order can be printed as separate pick lists and settled as separate payouts. This is the point where single-merchant storefronts break. A conventional e-commerce cart assumes one seller, one stock ledger and one payout destination. A hub needs the opposite: one cart, many stock ledgers, many payout destinations, and a delivery slot that only becomes available if every included producer can supply into that slot. That last constraint is easy to overlook. If a cheesemaker delivers to the hub on Thursdays only, their products cannot appear as available in a Wednesday collection round, and the checkout has to know that. Wholesale and retail customers also want different things from the same catalogue. A restaurant expects account pricing, ordering by case, a standing weekly order and payment on invoice. A household expects consumer pricing, ordering by piece and payment at checkout. Running these as two separate systems doubles the stock reconciliation work. Running them as two customer types against one stock pool is what keeps the hub's numbers honest. ### The pick, pack and route layer: where consolidated orders come apart on purpose Once orders close, the platform inverts the data: it groups every line item by producer to create purchase orders and pick lists, then regroups the arriving goods by customer to create pack lists, then groups packed boxes by route to create driver manifests. Same order data, three different views, generated rather than retyped. Two discrepancies always occur here, and a hub needs both to be captured at the moment they happen. The first is the producer shortfall: 40 kilos ordered, 34 delivered. The second is the pack-out discrepancy: the box was packed without an item because it was damaged or missing. Both change what the customer is charged and what the producer is paid, and both are recorded by whoever is standing at the crate, not by an administrator reconstructing the day from notes at 7pm. Routes then need to reflect real constraints rather than a map alone: chilled items grouped so the cold chain holds, collection points with fixed opening hours, customers who accept a doorstep drop and those who do not. The driver app's job is to record proof of delivery and any final failure, which closes the loop back to billing. Deliveries that failed on the doorstep are the last unrecorded event that can corrupt a settlement run. ### Multi-producer reconciliation: settling money in both directions Reconciliation in a hub means answering two questions for every order window: what did each customer actually receive and pay for, and what does each producer get paid after commission, shortfalls, packaging deposits, delivery contribution and tax. Both answers must be derived from the same delivered-quantity data, not from the ordered quantities. The distinction between ordered and delivered is the entire discipline. A settlement run built on ordered quantities will overpay producers who came up short and overcharge customers who received substitutions. So each line item needs three numbers carried through: ordered, supplied by the producer, and delivered to the customer. Commission is calculated on what was supplied. Customer charges are calculated on what was delivered. The gap between the two is the hub's shrinkage, and seeing it as a number per producer per week is one of the most useful reports a hub can have. Then there are the rules nobody writes down until a dispute forces them. Who absorbs the cent when a percentage commission does not divide cleanly. Whether the delivery fee is a flat customer charge or apportioned across producers by order value. How a returned crate deposit is credited. Whether a producer with a repeated shortfall carries the refund cost or the hub does. These are policy decisions, and software's job is to encode them consistently so the same answer comes out every week and every producer can see the workings on their own statement. ### Why one platform with four roles beats five integrated tools A single platform with distinct administrator, shopper, producer and driver interfaces keeps one copy of the order, stock and price data while giving each role only the screens they need. Integrating five separate tools reproduces the same workflow but adds sync lag, mapping errors and a permanent maintenance burden on whoever owns the integrations. The practical difference shows up in the small events. A producer marks 6 of 40 kilos unavailable at 8am. On one platform, the pick list, the affected customer orders, the pack list, the refund and the producer's expected payout all update from that one action. Across integrated tools, that action fires a webhook, or does not, and someone checks. Hubs run on thin margins with small teams, and the cost of that checking is rarely counted until an operations coordinator quits. There is also a governance argument. Producers stay in a hub when they trust the numbers. Giving each producer their own login where they can see their orders, their shortfalls, their commission line and their statement history removes most payment disputes before they start, because the producer is looking at the same record as the administrator rather than a PDF summary they have to take on faith. Plodie is built this way, as one data model behind four role-specific apps, because that is what hub operations actually need rather than a storefront with plugins bolted around it. ### Key Takeaways - A food hub's workflow is one chain: aggregate availability, publish a merged catalogue, take consolidated orders, split into pick lists, consolidate into deliveries, then reconcile money in both directions. - Consolidated ordering needs one cart with many stock ledgers, many payout destinations and slot availability that respects each producer's delivery days, which is exactly what single-merchant storefronts cannot do. - Every line item should carry three quantities: ordered, supplied and delivered. Commission is calculated on supplied, customer charges on delivered, and the gap is the hub's shrinkage. - Shortfalls and pack-out discrepancies must be recorded by the person holding the crate, at the moment they happen, or the settlement run will be wrong. - Rounding, delivery fee apportionment, deposits and shortfall liability are policy decisions first. Software's job is to encode them so every producer sees the same workings every week. For the reconciliation mechanics at the level of individual cents, see our [line-by-line teardown of a single settlement run](https://plodie.com/posts/the-anatomy-of-a-producer-payout-how-we-split-a-38-vegetable-box-between-11-grow), which splits a €38 vegetable box between 11 growers, the co-op and the van. ### Frequently Asked Questions #### What is the difference between a food hub and a farmers market platform? A farmers market platform typically keeps each producer's sales separate: the customer buys from several stalls and each seller fulfils their own items. A food hub takes physical and financial custody, aggregating goods into consolidated orders it packs, delivers and invoices under its own name. The hub therefore needs stock aggregation, pick and pack workflows and producer settlement, which market software often does not include. #### How do you handle a producer who delivers less than the quantity ordered? Record the shortfall against the specific line item at goods-in, before packing starts, so the system can decide which customer orders are affected using a documented rule such as first ordered first served, pro rata reduction, or substitution. The affected customers are then refunded or credited automatically and the producer is paid only for what they supplied. The key is capturing the shortfall once, at the crate, rather than reconstructing it later. #### Can a food hub sell to both restaurants and households from the same inventory? Yes, and it should, because splitting wholesale and retail into two systems doubles the stock reconciliation work. Run one stock pool with customer types that carry different price lists, minimum order values, units of sale, ordering windows and payment terms. Restaurants get case pricing and invoice terms, households get consumer pricing and checkout payment, and both draw down the same available quantity. #### What does a food hub need before migrating off spreadsheets? A cleaned producer list with bank details and commission rates, a product catalogue with consistent units and pack sizes, current price lists separated by customer type, delivery zones with slot rules, and written answers to the policy questions about shortfalls, rounding and delivery fee allocation. Most migration delays come from unresolved policy, not from data volume. Running one order window in parallel on both systems is the standard way to de-risk the switch. #### How much of a hub's admin time does an integrated platform actually remove? The savings concentrate in the repetitive transcription tasks: rebuilding pick lists, retyping orders between tools, chasing availability by phone and assembling producer statements by hand. Judgement work such as substitution decisions, producer relationships and route exceptions does not disappear. A realistic way to size it is to log the hours currently spent on each of those transcription tasks for two order windows before comparing platforms. ### Sources - [pmc.ncbi.nlm.nih.gov](https://pmc.ncbi.nlm.nih.gov/articles/PMC9250308/) - [cms.agr.wa.gov](https://cms.agr.wa.gov/WSDAKentico/Documents/DO/RM/RM/18_SellingThroughFoodHubs.pdf?_gl=1*1mnigzt*_ga*MTI3MDQ2MzM1LjE3MzUzMTcwNzc.*_ga_9JCK8SVQPE*czE3NTEwNjU2NjEkbzM0NSRnMSR0MTc1MTA2Njk3OCRqNjAkbDAkaDA.) - [ids.ac.uk](https://www.ids.ac.uk/projects/enhancing-effectiveness-of-multi-stakeholder-platforms-in-food-and-agriculture/) - [localline.co](https://www.localline.co/blog/best-food-hub-software) - [smartfds.co](https://smartfds.co/blog/food-hub-software/) --- ## The Co-op Dashboard Nobody Builds: 9 Metrics a Short Food Supply Chain Administrator Should Track Across 38 Producers URL: https://plodie.com/posts/the-co-op-dashboard-nobody-builds-9-metrics-a-short-food-supply-chain-administra Published: 2026-08-29 · Category: Product · By: Ivan Lauc Agritech dashboards stop at the farm gate. This is the co-op-level view: nine metrics a short food supply chain administrator should track across producers, shoppers and deliveries, and what to do when each one moves. ### Why co-op-level analytics falls into a gap nobody builds for Agritech analytics splits into two camps: farm management tools that measure yield, soil and irrigation for a single holding, and enterprise supply chain platforms built for pallet volumes and national distribution. A 38-producer co-operative sits between them, and its most valuable dataset, the one linking producers to shoppers to deliveries, has no default dashboard. The gap matters because the co-op administrator is the only person in the chain who can see across producers. A grower knows their own lettuce sold out on Thursday. They do not know that four other growers also listed lettuce that week, that the co-op oversupplied by 40 heads, and that the shoppers who wanted spinach found none. Only the aggregated view answers that, and answering it is the administrator's actual job: not growing, not driving, but deciding what the co-op should offer, from whom, and in what quantity. The other reason this dashboard rarely exists is that most co-ops never had the data in one place. When orders arrive by WhatsApp, prices live in a spreadsheet and payouts get reconciled by hand, there is no queryable history. The metrics below assume you have moved to a system that records every listing, order line, substitution and delivery outcome. That is the precondition, not the insight. ### The nine metrics, grouped by the decision they drive A co-op dashboard should be organised by decision, not by data source. Nine metrics cover the four recurring decisions an administrator makes: what to list, who to source from, how much to promise, and where the operation is leaking money. Each one should be readable in under ten seconds and drillable to a producer or product. Supply-side metrics tell you whether your producer base can deliver what you sell. Demand-side metrics tell you what shoppers actually want versus what you happen to be offering. Fulfilment metrics tell you whether the promise survived the van. And the mix metric, unsold rate by producer and by category, is the one that most directly converts into money left on the table or thrown away. - 1. Fill rate by producer: percentage of committed units a producer actually delivered on the day. The single best predictor of whether you can build a box around them next week. - 2. Listing consistency: how many weeks out of the last twelve a producer posted stock at all. Distinguishes a reliable weekly supplier from an occasional seasonal one. - 3. Producer concentration by category: what share of your tomato volume comes from your top supplier. Above roughly 60% in a staple category, one hailstorm empties your shelf. - 4. Category sell-through rate: units sold divided by units listed, per category, per week. Your clearest signal of over- or under-supply. - 5. Unmet demand signals: searches, out-of-stock views and abandoned baskets for items you had zero stock of. The metric that tells you what to recruit producers for. - 6. Basket composition drift: how the average order's category split moves week to week. Catches seasonal turns two to three weeks before your gut does. - 7. Repeat purchase rate by cohort: share of shoppers from a given signup month who ordered again within 30 days. The health check on the whole operation. - 8. Substitution and shortfall rate: how often an order line was swapped, reduced or refunded after the shopper paid. Where trust quietly erodes. - 9. Delivery success on first attempt: percentage of drops completed without a redelivery, a return to depot or a cold-chain write-off. ### How to read supply-side metrics across 38 producers without accusing anyone Fill rate, listing consistency and producer concentration are diagnostic, not disciplinary. A producer with an 80% fill rate is not unreliable; they are probably a small grower who lists optimistically. The correct response is to change how you plan around them, not to send a warning email. Sourcing decisions improve, relationships stay intact. In practice, this means segmenting producers rather than ranking them. Anchor producers with high fill rate and high listing consistency are the ones you can build a standing weekly box around. Seasonal specialists appear for six weeks a year with something nobody else has, and their low consistency score is a feature. Volatile suppliers with strong products but erratic delivery belong in surplus listings and add-ons, not in the guaranteed box. The dashboard's job is to tell you which bucket each of your 38 sits in this month, because the buckets move. Producer concentration is the metric administrators most often skip and most often regret skipping. If one grower supplies most of your potatoes, the risk is not just weather. It is a hospital stay, a broken tractor, or a better offer from a wholesaler. Tracking concentration by category converts a vague worry into a recruitment target: you need a second potato grower before September, not eventually. ### Turning demand data into product mix changes, not just charts Demand metrics only earn their place if they change next week's listing. The workflow is short: read sell-through by category, compare it to unmet demand signals, then adjust either the quantity you accept from producers or the producers you recruit. A category with 98% sell-through and repeated out-of-stock views is a sourcing gap, not a success. Sell-through above roughly 95% consistently means you are leaving revenue on the table and, worse, teaching shoppers that your leafy greens are usually gone by Tuesday. Sell-through below 70% means someone's crate is going home or into the compost, and if the same producer appears in that number three weeks running, the honest conversation is about volume, not quality. Neither number is actionable alone. Paired with unmet demand, they turn into a specific instruction: ask two growers for 30% more spinach, tell the third to hold back on courgettes. Basket composition drift is the quiet one. Watch the category share of an average order rather than absolute volume, and seasonal turns show up early. When the salad share starts sliding and root vegetables tick up while total order value stays flat, shoppers have decided autumn started. That is your cue to reshape the standard box and to tell growers what you will be buying, ideally before they have committed their own week. ### Forecasting co-op-level seasonal swings from your own history A co-op does not need machine learning to forecast. It needs two or three seasons of its own order history, indexed by ISO week, plus a note of what disrupted each anomaly. Comparing this week to the same week last year, adjusted for how many active shoppers you have now, gets you most of the way to a usable purchase plan. The practical method is to normalise. Raw order counts grow as the co-op grows, so a 20% year-on-year rise tells you nothing about demand per shopper. Divide by active shoppers in that week and you get a per-shopper baseline that survives growth. Then layer on the local calendar that generic forecasting tools never know about: school holidays, the week of the town festival, a public holiday that falls on a delivery day, and the fortnight when everyone's own garden produces more courgettes than they can eat and your courgette sales collapse. Keep an annotation log alongside the numbers. Every unexplained dip that you fail to write down becomes a permanent mystery in your history and a distorted forecast next year. Two lines in a shared document, "week 31: heatwave, three producers skipped harvest", is enough to keep the following year's plan honest. ### Building the dashboard: what to instrument first and what to ignore Start with four metrics, not nine. Fill rate by producer, category sell-through, substitution rate and first-attempt delivery success cover the failures that cost you money and customers this month. Add the demand and forecasting metrics once you have a full season of clean data behind them, because a trend line built on six weeks is noise with a slope. The instrumentation requirement is stricter than most co-ops expect. Fill rate needs a recorded commitment separate from the recorded delivery, so a producer's "I'll bring 20 kg" has to exist as data before the crate arrives. Substitution rate needs the original order line preserved rather than overwritten when the packer swaps an item. Unmet demand needs the storefront to log a zero-stock view, which nothing captures retroactively. Each of these is a small decision in how the system records events, and each one is impossible to backfill. Equally important is what to leave off. Vanity metrics like total registered producers, cumulative orders and page views do not drive a decision an administrator can act on this week. Neither does anything you cannot break down by producer or category, because the whole value of the co-op dataset is that it can be sliced by the people and products it describes. If a number cannot be attributed to a producer, a category or a delivery route, it belongs in an annual report, not on the operating dashboard. ### Key Takeaways - Farm software measures one holding and enterprise supply chain software measures pallets; the co-op-level view across producers, shoppers and deliveries is the dataset nobody builds a dashboard for. - Nine metrics cover the four decisions an administrator makes weekly: what to list, who to source from, how much to promise, and where money leaks. - Supply-side metrics like fill rate and listing consistency should segment producers into anchors, seasonal specialists and volatile suppliers, not rank them. - Sell-through paired with unmet demand signals turns charts into a specific instruction: buy 30% more spinach, hold back on courgettes. - Forecast from your own history normalised per active shopper, annotated with local events, and instrument commitments and substitutions from day one because they cannot be backfilled. None of these metrics exist until the order sheets leave the spreadsheet, which is what our [6-week migration plan](https://plodie.com/posts/from-spreadsheets-to-software-the-6-week-migration-plan-we-use-to-move-a-food-co) for moving a co-op's order sheets, price lists and routes into software is designed to fix. ### Frequently Asked Questions #### How many producers does a co-op need before analytics is worth the effort? Around eight to ten producers is where the aggregated view starts beating intuition. Below that, an administrator can hold every grower's reliability and every product's demand in their head. Above it, overlapping supply in the same category and unnoticed concentration risk begin to cost real money, and the patterns are no longer visible without recording them. #### What is a good fill rate for a small local producer? There is no universal benchmark, and treating a published one as a target usually backfires with smallholders whose harvest depends on weather. What matters is each producer's own stability: a grower who consistently delivers 85% of committed volume is more plannable than one swinging between 60% and 110%, because you can simply discount their commitments by a known factor when building the box. #### Can I build this dashboard in a spreadsheet? You can build the reporting layer in a spreadsheet, but not the capture layer. The hard part is recording producer commitments, original order lines before substitution, and zero-stock views as structured events at the moment they happen. If orders still arrive by phone and message, that data never exists, and no amount of spreadsheet work recovers it later. #### How do I share these metrics with producers without making them defensive? Share each producer their own numbers plus anonymised category-level context, never a public leaderboard. A grower who sees that their category ran at 68% sell-through across all suppliers understands a request to reduce volume as market information rather than criticism. Individual fill rate is best used in a planning conversation about realistic commitments, not in a performance review framing. #### Which of these metrics matter most for a co-op selling to restaurants rather than households? Fill rate, substitution rate and first-attempt delivery success become far more important, because a chef who receives 60% of an order has a menu problem that day. Demand metrics matter less because restaurant orders are typically standing and negotiated in advance, so the analytical weight shifts almost entirely to supply reliability and fulfilment accuracy. ### Sources - [arxiv.org](https://arxiv.org/html/2504.10058v1) - [pmc.ncbi.nlm.nih.gov](https://pmc.ncbi.nlm.nih.gov/articles/PMC7022380/) - [pubs.nmsu.edu](https://pubs.nmsu.edu/research/economics/RR789/index.html) - [dspace.mit.edu](https://dspace.mit.edu/entities/publication/61c15276-2fab-47f6-b975-427faa2c7ede) - [projectliberty.io](https://www.projectliberty.io/news/data-coops-as-alternative-to-centralized-digital-economy/) --- ## What a Food Co-op Actually Saves in Year One: A Line-by-Line ROI Model for Leaving Spreadsheets Behind URL: https://plodie.com/posts/what-a-food-co-op-actually-saves-in-year-one-a-line-by-line-roi-model-for-switch Published: 2026-08-28 · Category: Product · By: Ivan Lauc A concrete, line-by-line ROI model for a small food co-operative or food hub switching from spreadsheets to an integrated short food supply chain platform, covering admin hours, order errors, delivery cost per box, producer churn and sales lift. ### Why generic agritech ROI numbers don't apply to a 40-producer co-op Most published agritech ROI figures come from enterprise supply chains where the savings are in inventory carrying cost, freight consolidation and procurement leverage. A food co-op with 40 producers, 300 households and one chilled van has almost none of those levers. Its costs are labour, waste, failed deliveries and producer churn. This matters because the wrong model leads to the wrong decision. A board that expects "20% supply chain cost reduction" will be disappointed, because the co-op's landed cost is already short: one hop from farm to hub, one hop from hub to doorstep. There is no fat in the freight. The fat is in a co-ordinator spending Tuesday afternoon reconciling a producer's WhatsApp message against an order sheet that three people have edited. So the honest model for a small operation counts five things: administrative hours removed, the cost of order errors and credit notes, delivery cost per box, producer retention, and the sales volume the current system is quietly capping. Everything else is rounding. Build the model on those five and you can defend the number in front of a board or a grant assessor. ### Line 1: Administrative hours, the largest and most measurable saving Administration is where spreadsheet co-ops lose the most money, typically 10 to 20 hours a week for an operation running one or two delivery cycles with 30 to 50 producers. An integrated platform removes most of the transcription work, not the judgement work. Expect to eliminate the copying, not the deciding. Before you compare vendors, run a two-week time log. Ask whoever handles the cycle to write down minutes against each task. In the co-ops we have migrated, the log tends to break into the same buckets, and the buckets behave very differently under automation. Collecting availability from producers, transcribing it into a master sheet, building pick lists, splitting orders into routes, calculating producer payouts and issuing invoices are all pure transcription. They shrink by 70 to 90 percent when producers enter their own stock and orders flow into pick lists automatically. Customer service, quality complaints, recruiting producers and planning the season do not shrink at all, and you should not claim they will. The arithmetic is then simple. If the log shows 14 hours a week and 9 of those hours are transcription, an 80 percent reduction returns roughly 7 hours a week, or about 360 hours a year. Price those hours at whatever you actually pay, including employer costs. At a fully loaded €12 an hour that is around €4,300 a year. The important second question is what happens to the hours. If you cut a part-time contract, it is a cash saving. If you redeploy the co-ordinator into producer recruitment and customer retention, it is a growth investment and you should account for it under Line 5, not here. Counting it twice is the most common mistake in these models. - Transcription tasks that collapse: availability collection, master order sheet, pick lists, route splitting, payout calculation, invoice generation - Tasks that barely move: customer complaints, produce quality disputes, producer recruitment, seasonal planning, marketing - Tasks that appear new: keeping product data tidy, onboarding producers to the app, monitoring stock accuracy ### Line 2: Order errors, credit notes and the cost of a wrong box Order errors are the second-largest line and the most under-counted, because a co-op absorbs them as goodwill rather than recording them as loss. A wrong or short box costs the refund or replacement value, the produce itself, the return trip if one happens, and the staff time to resolve it. Realistic all-in cost is two to four times the item value. Count your errors for one month before you model anything. Pull every credit note, every refunded line, every "we'll add it to next week's box" message. Classify each one: was it a stock error (the item was not there), a picking error (it was there and did not get in the box), a data error (price or unit wrong on the sheet) or a delivery failure (right box, wrong destination or no one home)? Only the first three are meaningfully addressed by software. Stock errors fall when producers update their own availability and the storefront stops selling what is gone. Picking errors fall when pickers work from a generated list with quantities and producer codes instead of a printed spreadsheet. Data errors fall to near zero when price and unit live in one record instead of in a column that was last copy-pasted in March. Model it conservatively. A co-op doing 250 boxes a week with a 3 percent error rate has about 7.5 problem boxes a week. If the average all-in resolution cost is €14, that is €105 a week, roughly €5,500 a year. Halving it is a realistic first-year target, so €2,700. Do not model zero. Delivery failures and produce quality complaints persist regardless of the software, which is a separate operational problem with its own fixes. ### Line 3: Delivery cost per box, and why routing is the smallest saving Delivery is where boards expect the biggest win and where the win is usually smallest. For a co-op running one or two vans on a fixed weekly route, better routing typically saves 5 to 12 percent of the driving, worth a few hundred euros a year in fuel. The real delivery savings come from failed deliveries and pickup point consolidation, not from clever route maths. Work out your true cost per box first: van lease or depreciation, fuel, insurance, driver hours including loading, packaging and any cold chain equipment, divided by boxes delivered. Most small operations land somewhere between €3 and €7 a box, and are shocked, because they had been assuming the number from fuel alone. Once you have that number, the levers become obvious. Fewer failed deliveries means fewer boxes carried twice. Higher drop density on the same route lowers cost per box faster than shortening the route. Shifting marginal customers to a pickup point removes them from the van entirely. So model this line as three separate numbers rather than one. Routing efficiency: 5 to 10 percent of the fuel and driver-hour component. Failed deliveries: current failure count multiplied by the cost of a redelivery plus the value of any spoiled produce, halved. Pickup consolidation: the number of stops you can realistically move, multiplied by your per-stop cost. For a 250-box operation, that combination often totals €1,500 to €3,000 in the first year, which is real money but less than the admin line. Be sceptical of any vendor whose ROI case rests mainly on routing. ### Line 4: Producer retention, the line nobody puts a number on Every producer who leaves costs the co-op the gross margin on their volume plus the effort to replace them. Replacing a mid-sized producer takes a season: finding them, checking certification and capacity, listing products, teaching them the cycle. If your co-op loses three of 40 producers a year, that is a measurable, controllable cost. Producers leave short food supply chains for two reasons software can influence: payments that are late or unexplainable, and a listing process that costs more time than the sales are worth. A grower who cannot see what sold, at what price, and when they will be paid, will drift back to the market stall where the money is in the hand at the end of the day. A grower who has to send an availability message every Sunday night to a co-ordinator who may or may not read it in time will eventually stop sending it. To model this line, take the gross margin the co-op earns on an average producer's annual volume, multiply by the number of producers you lose each year, and estimate what portion of those departures were about payment clarity or listing friction rather than the producer retiring, expanding or having a bad harvest. Be strict here. If two of three departures were personal circumstances, only one is addressable. Retaining one mid-sized producer on €18,000 of annual sales at a 20 percent commission preserves €3,600 of co-op margin, and avoids the season of recruitment work. This line is easy to overstate, so keep the assumption visible in the model and let the board argue with it. ### Line 5: Sales lift, and the costs on the other side of the ledger Sales lift is the least predictable line and the one to model last. A co-op moving off spreadsheets typically gains volume from three sources: fewer out-of-stock listings, longer ordering windows, and the capacity freed up in Line 1 being spent on customer and producer growth. A 5 to 15 percent first-year lift is defensible. Anything higher needs a marketing plan attached. Then subtract the real costs, honestly. Platform subscription or licence. Implementation and data migration. Staff training time, which is genuinely disruptive for four to six weeks. Payment processing fees, which may be new if you were previously taking bank transfers. Hardware such as a tablet for the pack shed or phones for drivers. Producer onboarding time, roughly one to three hours per producer for the ones who need hand-holding. And the parallel-run period, where you pay for the software while still running the old sheets, which is a cost worth paying to de-risk the switch. Put it together for an illustrative 250-box-a-week co-op with 40 producers. Savings: admin €4,300, order errors €2,700, delivery €2,000, producer retention €3,600, plus whatever margin a 5 percent sales lift produces. Costs: subscription, implementation, training hours and hardware. Whether the first year is net positive depends almost entirely on two variables: how many admin hours your log actually shows, and whether you cut those hours or reinvest them. Run your own numbers into that structure before you take anyone's word for a percentage, including ours. - Savings lines: administrative hours, order errors and credit notes, delivery cost per box, producer retention, sales volume lift - Cost lines: subscription, implementation and migration, training time, payment fees, hardware, producer onboarding, parallel-run overlap - The two variables that decide the outcome: your true weekly admin hours, and whether freed hours become a cash saving or a growth investment ### Key Takeaways - Enterprise agritech ROI models don't transfer to small co-ops: the savings are in labour, errors, failed deliveries and producer churn, not freight or inventory carrying cost. - Administrative hours are the largest and most measurable line. Run a two-week time log and separate transcription work (shrinks 70 to 90 percent) from judgement work (doesn't shrink). - Routing is usually the smallest saving. Failed deliveries and pickup consolidation move cost per box far more than shorter routes. - Producer retention is the line most models omit. One retained mid-sized producer can be worth more than the entire routing saving. - Decide up front whether freed admin hours are a cash cut or a growth reinvestment. Counting them as both is the most common error in co-op ROI cases. Once the numbers stack up, the next question is sequencing: see our [6-week migration plan](https://plodie.com/posts/from-spreadsheets-to-software-the-6-week-migration-plan-we-use-to-move-a-food-co) for how the order sheets, price lists and delivery routes actually move across, including the parallel run that de-risks the switch. ### Frequently Asked Questions #### How much does software for a food co-op or food hub typically cost per year? Pricing for short food supply chain platforms usually combines a monthly subscription with an implementation and data migration fee, and sometimes a percentage of transaction value. For a small co-op the subscription is generally the smaller cost in year one; implementation, training time and the parallel-run overlap often exceed it. Always ask a vendor to quote the first-year total including migration, not just the monthly rate. #### Can a food co-op just keep using spreadsheets if it's small enough? Yes, and many should. Spreadsheets work reasonably well up to roughly five to ten producers and a hundred or so orders per cycle, where one person can hold the whole picture in their head. The breaking point is usually the second or third person editing the same sheet, or the point where producer payouts take longer than an evening to calculate. #### How long does it take to see a return after switching from spreadsheets? Expect the first four to six weeks to be net negative, because you are running old and new systems in parallel while training staff and onboarding producers. Administrative savings usually appear from the second full cycle on the new system. Error reduction and delivery savings take longer, typically a full season, because they depend on producers keeping their stock accurate. #### Will a grant funder accept an ROI model like this? Grant assessors generally respond well to models built on measured inputs rather than vendor percentages, so document your two-week admin time log, your month of credit notes and your true cost per box as evidence. Show conservative and optimistic cases separately, and state clearly whether freed staff hours are a cash saving or a reinvestment in growth. #### What if our producers won't use the app and we end up doing the data entry anyway? This is the single biggest risk to the ROI case, because the admin saving depends on producers entering their own availability. Before committing, pilot with your five least digitally confident producers rather than your most enthusiastic ones. If the platform can't get them posting stock with a phone call's worth of support, the admin line in your model will not materialise. ### Sources - [scholarworks.waldenu.edu](https://scholarworks.waldenu.edu/cgi/viewcontent.cgi?article=18976&context=dissertations) - [pmc.ncbi.nlm.nih.gov](https://pmc.ncbi.nlm.nih.gov/articles/PMC13076146/) - [strivepointt.com](https://www.strivepointt.com/insights/how-smes-can-replace-spreadsheets-with-scalable-systems) - [myshyft.com](https://www.myshyft.com/blog/administrative-time-savings-2/) - [business.com](https://www.business.com/articles/reduce-smb-admin-burden/) --- ## Calculating the Real ROI of a Short Food Supply Chain Platform: A Line-by-Line Business Case for a 40-Producer Co-op URL: https://plodie.com/posts/calculating-the-real-roi-of-a-short-food-supply-chain-platform-a-line-by-line-bu Published: 2026-08-27 · Category: Business · By: Ivan Lauc A numbers-first framework for building the business case for short food supply chain software, with a worked model for a 40-producer co-op covering admin hours, waste, producer churn and customer retention. ### Why generic supply chain ROI models don't work for a food co-op Standard supply chain and ERP ROI models assume inventory carrying cost, procurement leverage and warehouse throughput are the main savings levers. A short food supply chain has almost no inventory to carry, no procurement negotiation to optimise, and the largest cost centre is human coordination time. The value drivers are different, so the model has to be rebuilt. In a 40-producer co-op, stock exists for hours, not weeks. Nobody is financing a warehouse full of pallets. What actually consumes money is a coordinator reconciling order sheets against what showed up in the van, a producer chasing a payout query, a delivery slot missed because the customer was told the wrong window, and a crate of salad greens that was harvested for an order that got cancelled after cut-off. That means the four line items a board should be modelling are administrative labour, spoilage and shrinkage on the operating margin, producer retention, and customer retention. Two of those are cost avoidance and two are revenue protection. A credible business case shows both separately, because a finance committee will discount them at different rates. ### Line 1: administrative hours, the largest and most defensible saving Administrative labour is usually the biggest single line in an SFSC software business case because coordination time scales with the number of producers multiplied by the number of order cycles. To quantify it, count the hours spent per cycle on order collation, producer split calculation, payout preparation, route building and customer messaging, then price them at the loaded hourly cost of whoever does that work. The honest way to build this line is a time audit, not an estimate. Ask the coordinator to log a fortnight of work in six buckets: collecting and consolidating orders, sending pick lists to producers, checking deliveries in against orders, calculating producer settlements, building and adjusting delivery routes, and answering customer or producer queries by phone and message. Most co-ops running on spreadsheets discover the first four buckets dominate and that they grow roughly linearly with producer count. Then split the total into three categories rather than assuming software eliminates all of it. Some work is automated outright (recalculating a settlement when a line is short). Some is compressed, not removed (a route still needs a human eye, but the software proposes it). Some is untouched (a phone call with a producer who has had a bad week). A board will trust a model that admits the third category exists. Present the saving as a range, with the low end assuming only the fully automated bucket disappears. - Order collation and pick-list distribution: usually the highest-volume repetitive task, and the most fully automatable - Producer settlement calculation: high error risk on spreadsheets, near-total automation potential - Delivery route building: compressed rather than eliminated, human override still needed - Order-change handling after cut-off: partially automated, depends on the co-op's own policy - Producer and customer queries: largely untouched, but volume falls when both sides can see their own data ### Line 2: spoilage, shrinkage and the cost of harvesting the wrong thing Spoilage in a short chain is not mainly a cold-chain problem, it is a forecasting and communication problem. Producers harvest against a number they were given, and every gap between that number and the final order becomes unsold product. To value this line, measure the weight or value of produce that arrived at the hub and was not delivered to a paying customer, per cycle, for at least four cycles. The mechanics matter for the model. If a producer is told a provisional quantity on Monday and the real figure only settles on Wednesday, the difference is written off by somebody. Depending on the co-op's rules, that is either the producer's loss (which becomes a retention problem, see line 3) or the co-op's loss (which hits margin directly). Either way it belongs in the business case, and the co-op should know which of the two it is currently doing. Software reduces this line in specific, checkable ways: live order counts visible to producers instead of a weekly email, hard cut-offs enforced by the system rather than by goodwill, substitution rules that redirect a short line to another producer instead of cancelling it, and per-batch tracking so short-shelf-life stock is allocated first. Be conservative here. Claim a percentage reduction on measured waste, not a theoretical elimination of it. ### Line 3 and 4: producer churn and customer lifetime value Retention is where most of the upside actually sits, and where most business cases go silent because it feels unquantifiable. It is not. Producer churn has a measurable replacement cost (recruitment, onboarding, lost catalogue breadth), and customer churn has a measurable lifetime value (average basket multiplied by orders per year multiplied by years retained). Both respond to operational reliability. For producers, calculate what it costs to replace one. Time spent recruiting, farm visits, price-list setup, first-cycle hand-holding, plus the revenue lost while a gap sits in the catalogue. Then ask why producers leave. In our experience with Plodovi.hr and with co-ops migrating off spreadsheets, the recurring complaints are late or unexplained payouts, no visibility into what sold, and disputes about short-delivered lines that nobody can settle from records. Those are precisely the things a payout ledger and per-producer dashboard address, which makes the retention link defensible rather than hand-waved. For customers, the equivalent failure is a missed or wrong delivery. A household that receives a box with two missing items and no explanation is far more likely to skip the next cycle. Model this as: reduce cycle-over-cycle churn by one percentage point, multiply by the average customer lifetime value, multiply by active customer count. Even a single point is often worth more annually than the whole software subscription, which is why it is worth showing the board this line with its own sensitivity range. - Producer replacement cost = recruitment hours + onboarding hours + catalogue gap revenue - Producer churn drivers software can address: payout transparency, sales visibility, dispute records - Customer LTV = average basket x orders per year x expected years retained - Customer churn drivers software can address: accurate slots, honest substitutions, clear short-item refunds - Model retention as a range (0.5 to 2 percentage points) and show the break-even point inside it ### The worked model: a 40-producer co-op, assembled line by line A complete business case fits on one page: four benefit lines, three cost lines, and a payback period. The structure below is the template we hand to co-op boards. Fill it with your own audited figures rather than sector averages, because the numbers vary enormously between a weekly vegetable-box operation and a daily restaurant-supply chain. On the cost side, resist the temptation to show only the subscription. A board that later discovers unmodelled costs will distrust the whole document. Include the platform fee, any transaction or payment-processing fees, the one-off migration and data-cleaning effort (which is mostly your own staff time, not the vendor's invoice), and the productivity dip during the parallel run when the team operates two systems at once. That dip is real and typically lasts a few weeks. Then compute payback honestly. Take the conservative end of every benefit range, the full cost including internal time, and see when cumulative benefit crosses cumulative cost. If the conservative case pays back within a year, the decision is straightforward. If it only pays back on the optimistic case, that is useful information too: it means the co-op should either negotiate scope, run a smaller pilot, or wait until producer count grows enough to shift the labour line. - Benefit line 1: admin hours saved per cycle x cycles per year x loaded hourly cost - Benefit line 2: measured waste value per cycle x conservative reduction % x cycles per year - Benefit line 3: producers retained per year x replacement cost per producer - Benefit line 4: churn points avoided x active customers x customer lifetime value - Cost line 1: platform subscription and per-transaction fees for the year - Cost line 2: one-off migration, data cleaning and training, valued in internal staff hours - Cost line 3: parallel-run productivity dip, typically 2 to 6 weeks of partial double work - Output: conservative payback month, optimistic payback month, and annual net benefit at year two ### What the business case should not claim Credibility comes from what you leave out. Do not claim environmental or social benefits as cash unless the co-op has a funder or contract that actually pays for them. Do not claim revenue growth from software alone, because software does not create demand. Do not claim a saving on any hour of work the co-op will simply redeploy rather than stop paying for. Reduced food miles, better producer incomes and stronger local food resilience are genuine outcomes of a functioning short chain, and they matter enormously for grant applications, county partnerships and public-sector tenders. Put them in a clearly separate section labelled as non-cash benefits. If a specific grant or municipal programme does pay against them, then and only then move the relevant figure into the cash model with the funding source named next to it. The same discipline applies to labour. If your coordinator is salaried and stays salaried, the eight hours a week you free up is capacity, not cash. That capacity has real value, recruiting five more producers, launching a second delivery day, or finally answering restaurant enquiries within a day, but say so explicitly. A board that sees the distinction drawn for them tends to approve faster than one that has to find the flaw itself. Plodie's role in this is unglamorous: the platform is what makes the admin, waste and dispute lines move, and the migration plan is what determines how large the one-off cost line gets. ### Key Takeaways - SFSC ROI rests on four lines: administrative hours, measured spoilage, producer churn and customer lifetime value, not inventory carrying cost. - Audit two weeks of coordinator time in six task buckets, then split it into automated, compressed and untouched work before claiming any saving. - Include one-off migration effort and the parallel-run productivity dip as real costs, valued in internal staff hours. - Present every benefit as a range and report payback on the conservative end, not the optimistic one. - Keep environmental and social benefits in a separate non-cash section unless a named funder or contract actually pays against them. To size the one-off cost line accurately, work through our [6-week migration plan](https://plodie.com/posts/from-spreadsheets-to-software-the-6-week-migration-plan-we-use-to-move-a-food-co), which sets out exactly which internal hours a co-op needs to budget before the first live order. ### Frequently Asked Questions #### How much does short food supply chain software typically cost a co-op? Pricing models vary between a flat monthly platform fee, a percentage of transaction value, a per-producer seat charge, or a combination. For a board comparing options, the important step is converting every model into a single annual figure at your actual order volume and producer count, then re-running it at 150 percent of current volume to see how the cost scales with growth. #### How long before a food co-op sees a return on a new platform? Payback depends mostly on how much administrative time the co-op is currently spending and how many order cycles it runs per year. Operations with weekly cycles and a dedicated coordinator tend to see the labour line pay back fastest, while low-frequency or very small operations may take considerably longer. Model the conservative case and use its payback month as the decision figure. #### Can we justify the investment if our co-op only has 10 producers? Sometimes, but the case is weaker because the administrative labour line scales with producer count and order cycles. At 10 producers, the stronger arguments are usually error reduction in payouts and customer retention rather than hours saved. It can be worth waiting until producer count grows, or starting on a smaller scope and expanding. #### How do we measure food waste in our co-op before we have software? Run a manual log for at least four consecutive cycles. At the hub, record everything that arrived but was not delivered to a paying customer, with its wholesale value and the reason (order cancelled after cut-off, over-harvest against a provisional figure, quality rejection, damaged in transit). Four cycles is enough to see a pattern and gives you a baseline to measure improvement against later. #### Should we build our own system instead of buying a platform? Building is usually more expensive than it looks because the hard parts are not the storefront but multi-producer payout splitting, slot and route management, batch traceability and four different user roles. If you model the build option, include ongoing maintenance, hosting, compliance changes and the cost of a developer being unavailable during harvest season, then compare that annual total against the subscription. ### Sources - [content.ces.ncsu.edu](https://content.ces.ncsu.edu/local-food-systems-clarifying-current-research) - [extension.okstate.edu](https://extension.okstate.edu/programs/agribusinessand-cooperative-management/site-files/docs/newsletters/farmers-value-of-cooperatives-article.pdf) - [pmc.ncbi.nlm.nih.gov](https://pmc.ncbi.nlm.nih.gov/articles/PMC12603921/) - [cafnrfaculty.missouri.edu](https://cafnrfaculty.missouri.edu/cookml/wp-content/uploads/sites/26/2019/10/Obrien-Cook-2013.pdf) - [air.unipr.it](https://air.unipr.it/retrieve/2d400f90-00b9-48c6-8696-67060822ab0b/postprint.pdf) --- ## Onboarding a Grower Who Has Never Used an App: Designing for Low Digital Literacy in Local Food URL: https://plodie.com/posts/onboarding-a-62-year-old-grower-who-has-never-used-an-app-designing-software-for Published: 2026-08-26 · Category: Product · By: Ivan Lauc How to bring paper-and-phone-call producers onto a digital platform: the interface decisions, offline behaviour and onboarding sequence that get a 62-year-old grower posting stock without a training manual. ### Why the first login is the hardest part of the whole system The hardest technical problem in a short food supply chain is not payouts or routing. It is getting a producer who has never installed an app to complete one action, post available stock, without calling the co-op coordinator. If that action fails once, most growers revert to the phone call permanently and the platform quietly becomes a data-entry job for staff. The failure mode is predictable. A grower gets an invitation email they never open because their email is on a laptop their son set up. They download an app store app that asks for a password with a capital letter and a symbol. They see a dashboard with tabs for orders, products, invoices, settings and notifications and no obvious first move. Nothing in that sequence is broken. Each step just costs a small amount of confidence, and by step four there is none left. Designing for this user is not about big fonts. It is about reducing the number of decisions between opening the app and finishing the one task that matters this morning, and making sure every failure is recoverable without a support call. ### What actually blocks non-digital-native producers Four concrete blockers show up repeatedly with older and paper-based producers: account creation and passwords, ambiguous vocabulary, fear of irreversible mistakes, and patchy connectivity in fields and cold rooms. None of these are literacy problems in the pejorative sense. They are design problems that most software quietly outsources to the user. Passwords are the biggest single drop-off. A producer who writes prices in a notebook does not have a password manager, and a forgotten password flow that sends a reset link to an unused email address is a dead end. Vocabulary is the second. Words like SKU, variant, inventory, publish, draft and fulfilment do not map to how a grower talks about ten crates of lettuce that are ready on Thursday. Fear of mistakes is the third and the most underestimated: many producers hesitate on any button because they assume something will be sent to customers or the tax office and cannot be undone. Connectivity is real but often overstated in the wrong direction. The problem is rarely no signal at all. It is one bar in a polytunnel, so a form submit spins for twenty seconds and then throws an error after the data was actually saved. The producer then re-enters everything and ends up with duplicate listings, which teaches them the app cannot be trusted. ### Interface decisions that make an app usable on day one The design pattern that works is one screen, one job, in the producer's own words, with everything undoable. Replace a dashboard with a single question the grower can answer from memory: what do you have this week, and how much. Everything else, invoices, history, settings, moves behind a secondary screen they can ignore for months. Some specific decisions we keep coming back to when building producer-facing screens: - Phone number plus SMS code instead of email and password. No password to forget, and the phone is the device they already carry. - Last week's list pre-filled as the starting point. Most producers offer roughly the same items; the weekly task becomes editing quantities, not creating products. - Quantities in the units they use out loud: crates, bunches, kilos, bags. If the co-op needs a normalised unit for pricing, convert in the background. - Big, unambiguous primary buttons with verbs, not nouns. "Send my list" beats "Publish inventory". - A visible undo window and a plain confirmation screen: "Your list is sent. You can change it until Wednesday 18:00." Reversibility removes the fear that stops the first tap. - No modal dialogs, no tooltips, no onboarding carousel. Anything that must be dismissed before working is a barrier, not guidance. - Photos optional and never blocking. A grower who cannot get a decent photo of parsley should still be able to sell parsley. ### Building for one bar of signal, not zero Design for intermittent, slow connections rather than a binary online/offline state. Save locally on every field change, queue the submit, and tell the producer in plain language that the list is saved on the phone and will be sent when signal returns. Then send it once, with an idempotency key, so a retry never creates a duplicate listing. The behaviour that matters most is what the screen says while the network is bad. A spinner with no timeout teaches learned helplessness. A short message like "Saved on your phone. We will send it as soon as you have signal" plus a small pending badge lets the producer walk away and get on with picking. When the queue flushes, an SMS or push confirmation closes the loop: "Your list for Thursday was received: 12 crates lettuce, 8 kg tomatoes." Two more practical points. Keep the producer app light enough to work on a five-year-old Android phone on 3G, because that is the actual hardware in the field. And make every important confirmation available over a channel that does not require opening the app, since SMS is the one interface every producer in this group already trusts. ### A first-week onboarding sequence that sticks Onboarding a paper-based producer is a human process with software support, not a self-serve funnel. The sequence that works is: set the phone up together in person, do one real posting during that visit, keep paper running in parallel for two to three cycles, then remove the paper once the producer has completed two postings unaided. The in-person step is non-negotiable for this user group and it is shorter than people expect. Fifteen minutes with the coordinator covers installing the app, receiving one SMS code, and posting an actual list that actually reaches an actual order. The producer's first experience of the platform is a success, not a tutorial. Crucially, the coordinator holds their own phone and lets the producer tap. If the coordinator does the tapping, the producer learns nothing and calls again next week. Parallel running matters as much as the interface. For the first two or three delivery cycles the coordinator still accepts a phone call or a note, and enters it on the producer's behalf so that the record in the app matches reality either way. Nobody loses income because they were slow to adapt. Once a grower has sent two lists on their own, the phone-call fallback quietly stops being needed, and the ones who still prefer calling are visible in the data so the coordinator can spend time where it helps. - Visit 1 (15 minutes): install, SMS login, post a real list together, save the coordinator's number in the phone. - Cycle 1 to 3: paper or phone call still accepted, coordinator mirrors it into the app the same day. - Cycle 2 onward: coordinator sends a short SMS reminder before the cut-off instead of calling. - After two unaided postings: stop mirroring, keep the phone number as the exception route. - Ongoing: one named human to call. Not a ticket form, not a chatbot. ### How to tell whether onboarding worked Measure unaided completion, not logins. The signal that onboarding worked is the share of producers who post a list before the cut-off without staff intervention, plus the number of coordinator minutes spent entering data on someone else's behalf. Both are countable per delivery cycle and both are honest. A few other indicators are worth watching in a co-op setting. Time from opening the app to sending the list, because anything over two minutes means the screen is asking too much. Corrections made after sending, which usually reveal a unit or wording mismatch rather than carelessness. And support contacts per producer per cycle, which should fall towards zero for most and stay nonzero for a handful who genuinely need a different route. Some producers will never post their own lists, and that is a valid outcome rather than a failure. A good system keeps an admin-side path for a coordinator to enter stock for them in seconds, so the operation still gets clean data. That is one of the reasons Plodie splits the platform into separate producer and administrator apps over a shared data model: the person doing the typing can change without the rest of the chain noticing. ### Key Takeaways - The main barriers for non-digital-native producers are passwords, unfamiliar vocabulary, fear of irreversible actions and half-working connectivity, not age or intelligence. - Replace email-and-password with phone number plus SMS code, and pre-fill last week's list so the weekly task is editing numbers rather than creating products. - Design for one bar of signal: save locally, queue the submit, use idempotency keys so retries never create duplicates, and confirm over SMS. - Onboard in person in about 15 minutes with one real posting, then run paper in parallel for two to three delivery cycles before switching it off. - Track unaided postings before the cut-off and coordinator data-entry minutes, and keep an admin-side entry path for producers who will never self-serve. For the wider design system these producer screens sit inside, see our breakdown of the [UX decisions behind four apps that feel like one](https://plodie.com/posts/designing-four-apps-that-feel-like-one-ux-decisions-behind-a-multi-role-short-fo), covering how admin, shopper, producer and delivery interfaces share one data model without sharing one interface. ### Frequently Asked Questions #### Should I build a mobile app or just use SMS and WhatsApp for farmers who aren't tech savvy? Use both, for different jobs. Structured data entry (items, quantities, prices) belongs in an app or a mobile web form because free-text messages have to be retyped by staff, which defeats the purpose. Notifications, reminders and confirmations should go over SMS or WhatsApp, since those are channels producers already read without being asked to open anything new. #### How long does it take to onboard a small producer onto a local food platform? For a producer already used to smartphones, a self-serve signup and first listing can take under ten minutes. For a paper-based grower, plan on a single 15-minute in-person session plus two to three delivery cycles of parallel running with paper or phone calls accepted. The calendar time matters more than the training time. #### What if a producer refuses to use the app at all? Keep a coordinator-side entry path and treat it as a supported route, not a failure. An administrator should be able to enter a producer's weekly availability in seconds from a phone call, so traceability, stock and payouts stay complete. The cost is a few minutes of staff time per cycle, which is far cheaper than losing a good grower. #### Is designing for older users the same as accessibility compliance? They overlap but are not the same. Accessibility standards cover contrast, text size, touch target size and screen reader support, all of which help. Low digital literacy adds problems standards do not address: unfamiliar vocabulary, fear of irreversible actions, no password manager, and no mental model of how apps are structured. You need both. #### What is the single biggest cause of drop-off when onboarding non-digital-native users? Account creation. Email verification links, password rules and forgotten-password flows that depend on an email address the user rarely checks are where most first sessions end. Phone number plus a one-time SMS code removes the whole category of problem, because the code arrives on the device already in the user's hand. ### Sources - [pmc.ncbi.nlm.nih.gov](https://pmc.ncbi.nlm.nih.gov/articles/PMC12350549/) - [brookings.edu](https://www.brookings.edu/articles/overcoming-the-barriers-to-technology-adoption-on-african-farms/) - [extension.missouri.edu](https://extension.missouri.edu/news/adoption-of-precision-ag-varies-across-generations) - [digital.nsw.gov.au](https://www.digital.nsw.gov.au/delivery/accessibility-and-inclusivity-toolkit/design) - [nngroup.com](https://www.nngroup.com/articles/usability-for-senior-citizens/) --- ## The Last 200 Metres: What Actually Goes Wrong Between the Van Door and the Customer's Hand URL: https://plodie.com/posts/the-last-200-metres-what-actually-goes-wrong-between-the-van-door-and-the-custom Published: 2026-08-25 · Category: Product · By: Ivan Lauc Routing gets the van to the kerb. The failures happen after that. A field guide to the six ways a chilled box fails to reach a customer in a short food supply chain, what the driver and administrator each see, and which failures software can prevent versus which need a written policy. ### Why the last 200 metres, not the last mile, is where local food delivery breaks The last mile is a driving problem and routing software solves it well. The last 200 metres is a handover problem: parking, stairs, doorbell codes, absent customers, closing pickup points and empty crates. That stretch takes no fuel and generates almost every delivery dispute a co-op has to settle. The difference matters because the two stretches fail differently. A bad route costs you time and diesel, and you can see it in the numbers at the end of the week. A bad handover costs you a €38 box of perishables, a producer who does not get paid for goods that were physically delivered, a customer who wants a refund, and a crate that never comes back. None of that shows up on a route map. It also compounds. In a supermarket chain the driver drops a pallet at a loading bay and leaves. In a short food supply chain the driver is delivering twenty to sixty individual chilled boxes into residential buildings, on a fixed afternoon window, with items that were harvested that morning. Every failed handover is a perishable item with a clock running on it and a producer's name attached to it. ### The six failure modes, and what the driver actually sees on screen Six failures cover almost every failed drop in a short chain: the customer is not home, the building is not enterable, the pickup point closes before the van arrives, the goods are left with a neighbour, the box is refused on the doorstep, and the empty crate is not returned. Each one needs a different screen and a different resolution. The useful design question is not "how do we stop this" but "what does the driver tap in the thirty seconds they are standing at the door with a chilled box in their hands". If the app only offers Delivered and Failed, the driver will pick Delivered for the neighbour drop, pick Failed for the wrong doorbell code, and the back office learns nothing it can act on. Reason codes have to be specific enough that the administrator can route the consequence to the right person the next morning. The list below is the working taxonomy. It maps roughly to what a delivery app should offer as outcome buttons, and each item carries a different downstream cost. - Customer absent: doorbell rung, no answer, chilled box in hand and a clock on it. Needs a decision rule, not a driver's judgement call. - No building access: intercom broken, code changed, gate locked, courier code shared in a message the driver cannot see. The customer is often home and unaware. - Pickup point closed: the shop, café or locker that hosts the drop shut at 17:00 while the van was two stops away. Nobody is at fault and the goods still need somewhere to go. - Neighbour or concierge drop: the goods are handed to a person who did not order them. Delivery succeeded, chain of custody did not. - Doorstep refusal or damage: leaking bag, crushed berries, wrong item, or a customer who simply says no. Needs a photo and a return-to-depot flag before the van pulls away. - Crate not returned: the delivery worked perfectly and a deposit-bearing crate is still in the customer's kitchen. This is the most under-recorded failure in the whole chain. ### What the administrator sees, and why the back office view is a different job The administrator does not need six outcome codes. They need three queues: goods that came back on the van and need a decision today, money that is now in dispute, and packaging that is missing. A good back office collapses forty individual driver taps into those three action lists before anyone reads a single delivery note. The critical detail is that a failed drop is not one event, it is three unresolved threads. There is a physical thread (where is the box right now, is it still cold, can it be resold or must it be written off), a financial thread (does the customer get refunded, does the producer still get paid, who absorbs the loss), and a relational thread (does the customer get a message tonight or find out on Thursday). Software can close the first one automatically. The second two need a policy behind them. This is also where the returned-crate problem gets visible. If the driver logs crates collected per stop and the system holds a running deposit balance per customer, the administrator sees a list of households at three crates and rising. If crates are not logged at the door, the loss is invisible until someone counts the depot stack at the end of the season and finds a third of the fleet gone. ### Which failures software can genuinely prevent Software prevents the failures that come from missing information at the door: unknown access codes, unreachable customers, pickup points that will be closed on arrival, and untracked packaging. It cannot prevent a customer choosing to be out. The honest split is that roughly half the taxonomy is a data problem and half is a behaviour problem. The preventable set is worth building properly because each item removes a whole category of dispute rather than making it easier to argue about. Access instructions and a doorbell code belong on the address record, not in a chat message from three months ago, and the app should require them before an apartment address goes live for delivery. A pickup point should carry opening hours as structured data, and the route planner should refuse to sequence a stop that lands after closing time, or flag it loudly to the dispatcher. A customer should get an ETA message with a live window and a working reply channel, so absence turns into a reschedule at 14:00 rather than a failed drop at 16:40. What software cannot do is decide whether a chilled box may sit in an unheated stairwell for two hours in March, or whether the co-op eats the cost of a spoiled box when the customer forgot they had a dentist appointment. Those are policies. The most it can do is enforce them consistently once someone has written them down. - Prevented by data: missing entry codes, unknown floor or buzzer name, unreachable phone number, closed pickup point, unlogged crates, undocumented damage. - Prevented by process design: neighbour drops without consent, silent failures nobody tells the customer about, boxes that ride around in the van for the rest of the route. - Not preventable, only governed: customer absence, refusal at the door, weather, a building's caretaker refusing entry, a pickup host who closes early without warning. ### The five policies every co-op has to write before the software can help Before configuring any delivery app, a co-op needs written answers to five questions: how long may a chilled item be left unattended, who may accept on the customer's behalf, what happens to goods that come back on the van, who pays for a spoiled box, and how many crates a customer may hold before ordering stops. Software enforces these; it cannot invent them. Write them as thresholds, not principles. "We care about the cold chain" configures nothing. "Chilled items may be left in a shaded, sheltered location only between November and March, only with prior written consent on the address record, and never for meat, dairy or fish" is a rule a driver can follow and an app can enforce with a conditional button. The same applies to money: decide in advance whether the first failed delivery in a season is free and the second carries a re-delivery fee, and whether a producer is paid for goods that were picked, packed and loaded but never handed over. Producers usually should be paid in that case, because the failure happened after their obligation ended, and the co-op needs to price that risk into its margin rather than discover it at settlement. The crate policy is the one most operations skip. Deposits only work if the return is logged at the door and the balance is visible to the customer at checkout. A cap, say four outstanding crates before the next order is held, turns a slow leak of packaging into a two-line conversation. - Unattended-drop rule: which product categories, which months, which locations, and what consent is required on the address record. - Delegation rule: who may sign for a box (named neighbour, concierge, nobody) and whether the cold-chain guarantee survives the handover. - Return-to-depot rule: what happens to perishables that come back, what may be re-delivered tomorrow, what goes to staff or a food bank, what is written off. - Cost rule: who absorbs a spoiled box on a first failure versus a repeat, and whether a re-delivery fee applies. - Packaging rule: deposit value, maximum outstanding crates, and what happens at the cap. ### Turning failed drops into a weekly number worth looking at A short chain should review failed drops weekly by reason code, address and pickup point, not as a single percentage. One number tells you nothing. The same failure rate can mean one problematic apartment block, one pickup host with unreliable hours, or a delivery window that no longer matches when your customers get home. The patterns that surface are usually specific and fixable. Three failures at the same address in a month means the access instructions are wrong, not that the customer is difficult. A cluster of late-window failures across a whole neighbourhood means the route is sequenced backwards for that district's working hours. Repeated closures at one pickup point means the host relationship needs a conversation or the point needs replacing. Rising crate balances in one delivery zone usually means the driver on that run is not being prompted to ask. Photos and timestamps matter here for a reason that goes beyond dispute resolution. A proof-of-delivery record with a time, a location and an image is what lets a co-op say with confidence that a box left the depot cold at 13:10 and was in the customer's hands at 15:40. That is the same evidence trail that makes a refund decision fast and fair, and it is the difference between a member who trusts the service and one who quietly stops ordering after the second silent failure. ### Key Takeaways - Almost all delivery disputes in a short food chain happen after the van has parked, in the handover, not on the route. - Six failure modes cover most of it: absent customer, no building access, closed pickup point, neighbour drop, doorstep refusal, and unreturned crate. - Software reliably prevents the information failures (access codes, opening hours, ETA messages, crate logging); it cannot prevent absence or refusal. - Unattended drops, delegation, return-to-depot handling, who eats a spoiled box and crate caps are policies the co-op must write before any app can enforce them. - Review failed drops weekly by reason code, address and pickup point rather than as a single failure percentage. The same proof-of-delivery record that settles a dispute is the last hop in the chain of custody we describe in [batch-level traceability](https://plodie.com/posts/food-traceability-in-a-short-supply-chain-how-software-tracks-a-crate-from-growe), which follows a crate from grower to doorstep. ### Frequently Asked Questions #### Should a food co-op charge a re-delivery fee for a failed delivery? Most co-ops that charge one make the first failed delivery of a season free and apply a fee from the second onwards, because the first failure is usually a genuine mix-up and the second is a pattern. The fee should at least cover the driver time and the written-off perishables, and it must be published in the terms before the season starts. The alternative, absorbing every failure into commission, quietly transfers the cost to producers. #### Can a driver leave a chilled food box on the doorstep if nobody is home? Only under a written rule the customer has agreed to in advance, and normally never for meat, dairy, fish or prepared foods. A workable policy limits unattended drops to a sheltered location, to cooler months, to lower-risk product categories, and requires consent recorded on the address record rather than a verbal arrangement with one driver. Without that, the co-op carries the full liability for anything that spoils. #### Do producers get paid when a customer never receives their delivery? Usually yes. The producer harvested, packed and handed over the goods, so their obligation ended before the failure occurred. The co-op or the delivery operation absorbs the loss and should price that risk into its margin. Deciding this in advance matters, because at settlement time an unallocated loss will otherwise be split arbitrarily and someone will feel cheated. #### How do you stop customers keeping the reusable crates? Log crate returns at the door as part of proof of delivery, hold a running deposit balance per household, and show that balance to the customer at checkout. Set a cap, for example four outstanding crates, after which the next order is held until crates come back. Deposits alone do not work if nobody records the return. #### What is the difference between last mile delivery and the last 200 metres? Last mile refers to the drive from the depot or hub to the customer's neighbourhood, and it is a routing and vehicle problem. The last 200 metres is everything after the van parks: parking, building access, stairs, the handover itself and collecting empty packaging. Routing software optimises the first; only proof-of-delivery workflows and clear policy handle the second. ### Sources - [genicsolutions.com](https://www.genicsolutions.com/delivery-route-optimisation-how-to-reduce-failed-deliveries-and-improve-eta-accuracy/) - [fixlastmile.com](https://www.fixlastmile.com/blog/top-courier-delivery-challenges-and-solutions/) - [item.com](https://www.item.com/order-management-system/shipping-and-delivery-failed-delivery-handling) - [emergentcoldlatam.com](https://emergentcoldlatam.com/en/logistics/last-mile-in-logistics/) - [supplychaindive.com](https://www.supplychaindive.com/spons/cold-chain-on-the-brain-3-key-challenges-for-last-mile-distribution/727041/) --- ## Food Traceability in a Short Supply Chain: How Software Tracks a Crate From Grower to Doorstep URL: https://plodie.com/posts/food-traceability-in-a-short-supply-chain-how-software-tracks-a-crate-from-growe Published: 2026-08-24 · Category: Product · By: Ivan Lauc How batch-level traceability actually works in a short food supply chain: what data to capture at each hop, how to run a one-hour recall, and what to hand an inspector who asks where a crate of lettuce came from. ### What does traceability legally require in a short food supply chain? In the EU, Regulation 178/2002 requires every food business to know its direct supplier and its direct business customer, the "one step back, one step forward" rule, and to produce that information to authorities on demand. Sales to final consumers are exempt from the forward step, but the backward step still applies. That single sentence hides a lot of practical work for a co-operative or food hub. If you buy from 40 growers and sell to consumers, restaurants and a school kitchen, you are a food business operator in your own right. You need records of what you received, from whom, in what quantity and when, plus records of what you dispatched to each business customer. Consumer orders do not need forward traceability by law, but most operators keep it anyway because it is the fastest way to answer a complaint. Some products carry extra obligations on top of the baseline. Fresh fruit and vegetables sold under EU marketing standards need the producer, packer or dispatcher identified on the packaging or documents. Eggs carry producer codes. Beef has its own dedicated traceability regime. Organic certification adds a parallel audit trail: the certifier wants to see that the organic quantity you sold never exceeded the organic quantity you bought. If you run a shared kitchen or process anything, HACCP records join the pile. National rules vary, so treat this as the shape of the obligation and confirm specifics with your competent authority. ### What data has to be captured at each hop from field to doorstep A traceable crate needs four anchors: who produced it, which batch or lot it belongs to, how much of it existed, and which orders consumed it. Everything else, temperature, harvest date, certification status, hangs off those four. Capture them at the moment the crate changes hands, not in a Sunday evening catch-up session. The practical trick in a short chain is that there are only three or four handovers, so each one can be a deliberate, recorded event rather than an inference from paperwork. A grower confirms what they are bringing. A hub operator receives and checks it. A picker assigns quantities to orders. A driver confirms the drop. Each of those touchpoints already happens; traceability just means writing down the identifiers while the crate is in front of someone. The unit of traceability matters as much as the fields. A batch that means "everything Marko brought on Tuesday" is easy to record and gives you a recall scope of one delivery day. A batch that means "the 09:00 cut from the north polytunnel" is more work at intake and narrows a recall to a handful of orders. Small operations should pick the coarser unit first and tighten it for high-risk products such as leafy greens, raw milk products and sprouts. - Intake: producer ID, product, batch or lot reference, quantity received, date, unit of measure, condition notes, certification status at time of receipt - Storage: location or zone, any repacking or splitting event that creates a child batch from a parent batch - Picking and packing: which batch fed which order line, in what quantity, packed by whom - Dispatch: route, driver, vehicle, departure time, cold chain notes if applicable - Delivery: timestamp, recipient confirmation, pickup point or address, any refusal or substitution - Documents attached to the above: delivery notes, invoices, certificates, lab results, photos of labels ### How software turns those records into a one-hour recall A recall is two queries. Forward: given a batch, list every order, customer and delivery that received any of it. Backward: given a complaint about one delivered item, name the batch, the producer and every other order that shares that batch. Software answers both in seconds because the link between batch and order line was written at pick time. On a spreadsheet the same questions take hours of cross-referencing between an intake sheet, an order sheet and a delivery list, and they usually end in a phone call to whoever packed that day. The gap is not effort, it is that spreadsheets store the three events in three places with no enforced key between them. A shared batch identifier that every app writes to is the whole mechanism. Once the queries are instant, a few useful behaviours become cheap. You can send a targeted notice to only the 23 households that got the affected batch instead of alarming your entire customer list. You can tell the producer exactly how much of their lot is still in the cold room versus already delivered. You can hold the remainder of a batch with one action so pickers stop assigning it mid-recall. And you can export the whole chain, intake to doorstep, as a single document for the authority handling the incident. ### What an inspector actually asks for, and what to hand over Inspectors rarely ask to see your software. They ask a question about a specific product and time frame, then judge how quickly and consistently you can answer it. A typical challenge is: show me where this batch came from, where it went, and prove the two quantities reconcile. Have that as an exportable record, not a screen you have to narrate. Prepare three artefacts in advance. First, a written traceability procedure describing your batch unit, who records what at each step, and how long you retain records. Second, a mock recall you have actually run, with the date, the batch chosen, the time taken and the list of affected customers. Regulators and certifiers respond well to evidence that you have tested the system rather than described it. Third, a live certificate register: organic certificates, HACCP documentation, registration numbers and their expiry dates, each attached to the producer it belongs to so an expired certificate is visible before an inspection, not during one. The reconciliation point deserves attention because it is where paper-based operations usually fail. If you received 120 kg of a batch and your order lines total 138 kg, something is wrong: a mislabelled crate, a manual override, or product from a second producer sold under the first one's name. Software that decrements batch quantity as orders are picked makes that impossible to do accidentally and surfaces it immediately when someone tries. - A one-page traceability procedure naming your batch unit and record retention period - Intake records with producer, batch, quantity and date for the requested period - Dispatch and delivery records linking those batches to customers and timestamps - A dated mock recall report showing scope and elapsed time - Certificates on file per producer, with expiry dates and the products they cover ### Turning the same data into a selling point on the product page The records you keep for compliance are also the most credible marketing asset a local food business has. The same producer and batch fields that answer an inspector's question can populate a product page that names the farm, the village, the harvest week and the certification, without anyone retyping it into a CMS. Shoppers in short chains buy on provenance, and vague provenance claims are increasingly easy to distrust. "Local" is a word anyone can print. "Harvested 12 June by Obitelj Kovač, Baranja, organic certificate valid to March" is a claim tied to a record. Because the data is entered once by the producer at intake, the storefront statement and the compliance record cannot drift apart, which is exactly the failure mode of hand-maintained producer bios. A QR code on the delivery box or crate label that resolves to the batch's public page closes the loop. Consumers see origin and date. Restaurant buyers get the documentation they need for their own menu claims and their own inspections. And the co-operative gets a reason for producers to keep intake records accurate, because those records are what their customers read. Plodie's producer, admin, shopper and delivery apps write to one shared record for exactly this reason: the batch a grower confirms in the morning is the batch a driver marks delivered in the afternoon and the batch a customer reads about on the label. ### Key Takeaways - EU law requires one step back and one step forward traceability; consumer sales are exempt from the forward step, but everything you receive still needs a supplier record. - Capture four anchors at every handover: producer, batch, quantity and the orders that consumed it. Everything else attaches to those. - Choose a coarse batch unit first, such as one producer's delivery on one day, and tighten it only for high-risk products like leafy greens and raw milk. - Run and document a mock recall. Inspectors and certifiers trust a tested system more than a described one. - The same producer and batch data that satisfies an audit can populate provenance claims on the product page without duplicate data entry. If your intake, order and delivery records currently live in three separate spreadsheets, our [6-week migration plan for food co-operatives](https://plodie.com/posts/from-spreadsheets-to-software-the-6-week-migration-plan-we-use-to-move-a-food-co) covers how those columns map into a single traceable record. ### Frequently Asked Questions #### Do small farms and market stalls need traceability records, or is it only for big producers? Primary producers selling small quantities directly to final consumers or to local retailers are treated more lightly under EU rules, and member states set their own detailed requirements for that activity. But once you sell through a co-operative, food hub or another business, that business needs a record of you as its supplier, and you need to be able to identify what you supplied and when. In practice a simple delivery note per drop, with product, quantity and date, satisfies most of it. #### How long do I have to keep food traceability records? The common guidance in the EU is five years from the date of manufacture or delivery for most products, with shorter periods allowed for highly perishable goods with a durability under three months, often set at the shelf life plus six months. Check your national authority, because implementation differs. Digital records make retention trivial compared to boxes of delivery notes. #### Can I do traceability with a spreadsheet instead of software? Yes, and many small operations legally do. A spreadsheet fails on speed and on reconciliation: cross-referencing intake, orders and deliveries by hand during an actual incident takes hours, and nothing stops you selling 138 kg of a 120 kg batch. Software is worth it once you handle multiple producers, since the shared batch identifier is what makes the recall query instant. #### What is the difference between traceability, HACCP and organic certification? Traceability is knowing where food came from and where it went. HACCP is a hazard control system for processing operations, identifying critical control points such as chilling temperatures and setting limits and monitoring for them. Organic certification is a third-party audit that your products and quantities match certified organic inputs. They overlap in the records they need, which is why one well-structured data set can feed all three. #### What should a QR code on a local food product actually show the customer? Useful content is the producer name and location, the harvest or production date, the batch reference, any certifications with their validity, and how the product reached the customer. Avoid pages that only show marketing copy, because the point is that each claim maps to a stored record. Restaurant and retail buyers often use the same page as supporting documentation for their own menu and shelf claims. ### Sources - [fda.gov](https://www.fda.gov/food/hfp-constituent-updates/now-available-small-entity-compliance-guide-food-safety-modernization-act-fsma-food-traceability) - [rsmus.com](https://rsmus.com/insights/industries/food-beverage/compliance-guidance-for-fsma-food-traceability-rule.html) - [wiliot.com](https://www.wiliot.com/blog/fsma-204-food-safety-modernization-act-food-traceability) - [easconsultinggroup.com](https://easconsultinggroup.com/food-traceability-rule-fsma-204/) - [documentcompliance.com](https://documentcompliance.com/best-food-traceability-software/) --- ## The Anatomy of a Producer Payout: Splitting a €38 Vegetable Box Between 11 Growers, the Co-op and the Van URL: https://plodie.com/posts/the-anatomy-of-a-producer-payout-how-we-split-a-38-vegetable-box-between-11-grow Published: 2026-08-23 · Category: Product · By: Ivan Lauc A line-by-line teardown of one settlement run: how a €38 vegetable box is split between 11 producers, the co-operative's commission, packaging deposits, delivery cost and VAT, including the rounding and dispute rules that decide who absorbs the cent. ### What is actually inside a €38 vegetable box before anyone gets paid? A €38 box is not €38 of vegetables. In the run we are dissecting, the shopper paid €38.00 for a box containing €30.15 of produce lines from 11 producers, €2.50 of delivery, €2.00 of returnable crate deposit, and the rest is the co-operative's margin embedded in the shelf prices. Settlement means unwinding that back into 11 payable amounts. The first mistake most co-ops make on a spreadsheet is treating the box as a single product with a single cost. It is not. It is a bundle of line items, each one attached to a producer, a unit, a quantity picked, a quantity ordered and a price. A box priced at €38 that contains 14 lines can only be settled correctly if every one of those 14 lines is tracked individually from order through picking to delivery. If the picker substitutes one item, the split changes, and the box price does not. Here is the shape of the box as it went out. Prices are shelf prices, what the shopper sees, inclusive of the co-op's margin. - Potatoes, 3 kg, Producer A, €4.50 - Carrots, 1 kg, Producer B, €1.80 - Onions, 1.5 kg, Producer B, €2.10 - Mixed salad leaves, 200 g, Producer C, €2.40 - Cherry tomatoes, 500 g, Producer D, €3.20 - Cucumbers, 2 pcs, Producer E, €1.90 - Courgettes, 1 kg, Producer E, €2.30 - Kale, 1 bunch, Producer F, €1.95 - Beetroot, 1 kg, Producer G, €2.20 - Leeks, 2 pcs, Producer H, €2.10 - Garlic, 3 heads, Producer I, €2.70 - Free-range eggs, 10 pcs, Producer J, €3.60 - Apples, 1 kg, Producer K, €1.90 - Delivery to pickup point, €2.50 - Crate deposit (refundable), €2.00 ### How is the co-operative's commission calculated, flat or per-producer? Commission is deducted from each line's shelf price, not from the box total. Our default is a flat rate, 18% in this example, but the model supports a per-producer override, and in practice most co-ops end up with two or three tiers. The arithmetic is identical either way: producer payout per line equals shelf price multiplied by (1 minus that producer's rate). A flat rate is simpler to explain and easier to defend at a general assembly. It breaks down the moment the co-op does genuinely different amounts of work for different producers. The grower who delivers pre-weighed, pre-labelled bags to the hub at 06:00 costs the co-op far less handling than the one whose kale is collected from the farm and bunched by co-op staff. Charging both 18% is a subsidy flowing from the first to the second, and the first one eventually notices. So the rule we settled on is that the rate is a property of the producer agreement, defaulting to the co-op's standard rate, with overrides recorded with a reason and an effective date. Effective date matters more than it sounds. If a rate changes mid-fortnight, every line settles at the rate in force on the delivery date, not the payout date, otherwise a producer can be paid two different amounts for two identical deliveries in the same week. - Flat rate: one percentage for all producers. Transparent, trivial to audit, quietly unfair when handling effort differs. - Per-producer rate: negotiated per agreement. Fairer, needs a written reason per override or it becomes favouritism. - Tiered by service level: e.g. 14% for hub drop-off, 18% for standard, 24% when the co-op collects and packs. Our recommendation for co-ops above roughly 15 producers. - Per-category rate: lower on high-value, low-handling goods such as honey or oil, higher on wet, perishable, weight-loss-prone produce. ### Who pays for a short weight, a refused item or a substitution? The rule is simple to state and hard to apply: the party that caused the variance absorbs it. Short weight is deducted from the producer who supplied it, refused-on-quality items are deducted from the producer, a co-op picking error is absorbed by the co-op, and a substituted item is credited to the substitute grower, never the original one. Every deduction carries a reason code. Take the courgettes. Producer E was ordered 1 kg per box across 40 boxes and delivered 37.2 kg. The co-op filled the last three boxes short at 0.6 kg. Those three boxes shipped with 0.6 kg instead of 1 kg, and the shopper was credited €0.92 each at shelf price. That credit is recovered from Producer E's settlement, net of commission, because the co-op should not lose its margin on the volume it did sell, nor earn margin on volume that never existed. In line terms, Producer E is paid for 37.2 kg at €2.30 per kg less 18%, and the shopper credit is handled at shelf price against the box. Substitution is where spreadsheets go wrong most often. Producer C's salad leaves failed quality check on the morning of packing, and 12 boxes went out with Producer F's chard instead at the same €2.40 shelf price. If the settlement sheet is built from the order, Producer C gets paid for 12 bags of leaves they never delivered. Our settlement is built from the delivery note, not the order, so the €2.40 line for those 12 boxes moves to Producer F entirely. Producer C receives nothing for them and no penalty beyond the lost sale, unless the failure was a repeat, in which case the co-op's quality policy, not the accounting engine, is the right tool. - SHORT_WEIGHT: producer supplied less than picked quantity. Deducted from producer at net price. - QC_REFUSED: item rejected at the hub. Line removed from producer settlement entirely. - SUBSTITUTED: line reassigned to the substitute producer at the shelf price actually charged. - PICK_ERROR: co-op packed the wrong item or missed one. Shopper refunded, cost absorbed by the co-op. - DAMAGED_IN_TRANSIT: absorbed by the co-op's delivery budget, not the producer, once goods have been accepted at the hub. ### How are delivery cost, packaging and crate deposits recovered? Delivery is charged to the shopper as a visible line, not apportioned across producers. Packaging that is consumed, bags and paper, is inside the co-op's commission. Returnable crates carry a €2.00 deposit that is a liability, not revenue: it never touches any producer's settlement, and it is refunded or rolled forward when the crate comes back. We tried apportioning the van across producers early on, splitting the route cost by line value. It is defensible in theory and unworkable in practice. A grower whose €1.90 of apples travels in the same box as €30 of other produce ends up with an opaque €0.11 deduction they cannot verify, and the deduction moves every week depending on who else happens to be in the box. Producers stopped trusting the number. Charging delivery to the shopper as an explicit €2.50 makes the box price honest and keeps every producer statement free of costs they cannot influence. There is one exception. Farm collection, where the van makes a detour to a producer instead of the producer delivering to the hub, is a service the co-op provides to that specific producer, and it is recovered either through a higher commission tier or a fixed per-stop fee agreed in advance. That is a cost the producer can actually influence, by delivering to the hub instead, which is exactly the property a fair deduction needs. Crate deposits sit in their own ledger: €2.00 charged, €2.00 refunded on return, and unreturned crates written off against the shopper's deposit after a set number of cycles. ### How do VAT-registered and non-registered smallholders settle differently? Both are paid the same net amount for the same goods, but the paperwork differs. A VAT-registered producer's settlement is a self-billed invoice showing net, VAT and gross, with VAT payable on top of the net figure. A non-registered smallholder's settlement is a purchase document with no VAT line at all, and the co-op cannot reclaim input VAT on those goods. The trap is that shelf prices are usually set VAT-inclusive, because that is what the shopper pays. If your settlement engine calculates producer payout as a percentage of a VAT-inclusive shelf price without first stripping the VAT, you will pay VAT-registered and non-registered producers different net amounts for identical goods, and neither of them will be able to tell you why. The correct sequence is: shelf price to net-of-VAT, then commission, then add the producer's own VAT if applicable. Concretely, at a 5% rate on fresh produce, a €2.30 shelf price is €2.19 net. Commission of 18% leaves €1.80 to the producer. A registered producer then invoices €1.80 plus €0.09 VAT, gross €1.89. A non-registered producer receives €1.80 flat. The co-op's margin is €0.39 in both cases. Getting this order of operations wrong is one of the most common defects we find when migrating a co-op off spreadsheets, and it usually shows up as a producer complaining that they are paid less than a neighbour for the same lettuce. ### What do the rounding rules and the fortnightly reconciliation view look like? Rounding happens once, at the producer total, not per line, and it rounds to the cent in the producer's favour. Half-cent differences accumulate into a rounding account owned by the co-op, which typically nets out to under a euro per settlement run. Producers see a single reconciliation screen: opening balance, lines delivered, deductions, adjustments, net payable. Rounding per line is where cents disappear. If Producer B has 40 lines of carrots at €1.80 shelf, each netting €1.4759, rounding each line to €1.48 pays €59.20 while rounding the total pays €59.04, a sixteen cent gap that nobody can explain from the statement. Rounding once at the bottom, on a total computed at four decimal places, is both cheaper and easier to defend. The co-op absorbs the residual because the co-op, not the grower, chose the pricing scheme that created it. We moved from monthly to fortnightly settlement after three specific disputes. The first was a substitution paid to the wrong grower and only spotted five weeks later, by which time the picking notes were gone. The second was a short-weight deduction a producer could not reconstruct because it was buried inside a month of aggregated lines. The third was a crate deposit treated as revenue in one month and as a liability the next. Shorter cycles do not prevent errors, they just keep the evidence fresh enough to resolve them. Fortnightly also matches how most small growers manage cash, and the reconciliation view in the Producer app is deliberately built to be readable on a phone in a field, because that is where it gets opened. - Opening balance carried from the previous run, including anything disputed and held - Delivered lines: product, date, quantity accepted, unit price, gross, commission rate, net - Deductions with reason codes and a link to the specific delivery note or shopper credit - Adjustments: crate deposits reconciled, per-stop collection fees, corrections from prior runs - Net payable, VAT treatment, and the payment reference the transfer will carry ### Key Takeaways - Settle from the delivery note, not the order, so substitutions credit the grower who actually supplied the goods. - Deduct commission per line at the rate in force on the delivery date, and strip VAT from the shelf price before applying it. - Charge delivery visibly to the shopper rather than apportioning van cost across producers who cannot influence it. - Treat crate deposits as a liability in their own ledger, never as revenue and never inside a producer's payout. - Round once at the producer total, not per line, and let the co-op absorb the residual cent. If you are still trying to run this arithmetic on top of a single-merchant storefront, we wrote about [why Shopify breaks at the second producer](https://plodie.com/posts/why-shopify-breaks-at-the-second-producer-what-happens-to-payouts-stock-and-pick), where payouts, shared stock and pickup slots all hit the same wall. ### Frequently Asked Questions #### How often should a food co-operative pay its producers? Fortnightly is the sweet spot for most small co-ops. Weekly creates a lot of administrative churn and bank fees for small amounts, while monthly means disputes surface after the picking notes, weigh slips and delivery records have gone stale. Fortnightly keeps evidence fresh and matches how most small growers manage cash flow. #### What commission rate do food co-operatives usually charge producers? Rates vary widely because they cover different amounts of work. A co-op where producers deliver pre-packed goods to a hub can operate on a lower rate than one that collects from farms, grades, weighs and packs. The important thing is that the rate is written into the producer agreement with an effective date, and that any override from the standard rate has a recorded reason. #### Should the shopper or the producers pay for delivery in a farm box scheme? Charge it to the shopper as a visible line on the order. Apportioning van cost across producers produces small deductions that change every week depending on which other producers happen to be in the box, which producers cannot verify or influence. The exception is farm collection, a service the co-op provides to a specific producer, which is fairly recovered through a per-stop fee or a higher commission tier. #### How do you handle a producer disputing a deduction on their settlement? Hold the disputed amount rather than reversing or ignoring it, carry it into the next run as an explicit opening balance line, and resolve it against the underlying delivery note or shopper credit. Every deduction should carry a reason code and a link to the source document, so the conversation is about the evidence rather than about who remembers the week correctly. #### Can a co-op run producer settlement in a spreadsheet? Yes, up to a point, and most co-ops start there. Spreadsheets hold up while lines per run are low and substitutions are rare. They break when you need per-producer commission rates with effective dates, reason-coded deductions linked to delivery notes, a separate crate deposit ledger and different VAT treatment per producer, because each of those adds columns that have to stay consistent across every historical run. ### Sources - [fca.gov](https://www.fca.gov/bank-oversight/the-cooperative-way) - [uwcc.wisc.edu](https://uwcc.wisc.edu/about-co-ops/types-of-co-ops/) - [docs.lib.purdue.edu](https://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1017&context=socpubs) - [agsouthfc.com](https://www.agsouthfc.com/articles/seven-principles-cooperative) - [prodapi.i-aps.com](https://prodapi.i-aps.com/filespdf/c05de265-6d33-4295-b838-f0e9d134ab46.pdf) --- ## Why Shopify Breaks at the Second Producer: Payouts, Stock and Pickup Slots When 40 Growers Share One Storefront URL: https://plodie.com/posts/why-shopify-breaks-at-the-second-producer-what-happens-to-payouts-stock-and-pick Published: 2026-08-22 · Category: Product · By: Ivan Lauc A single-merchant storefront works for one farm and breaks at the second. Here are the six points where Shopify fails a multi-producer farmers market, the workarounds operators try, and what the operation actually needs. ### Shopify works fine for one farm. What changes at the second producer? A single-merchant storefront assumes one seller, one inventory, one bank account and one fulfilment point. Add a second producer and every one of those assumptions splits in two: the basket now contains goods from two businesses that must be picked separately, paid separately, and confirmed separately. This is not a theme or plugin problem. It is a data model problem. In a single-merchant store, a product belongs to the store. In a market, a product belongs to a producer, and the producer is an economic actor with their own availability, their own price, their own commission rate and their own payout. The moment you need to answer "how much does Ivan get paid this week and for exactly which lines," you are asking a question the storefront has no field for. Most operators do not discover this at setup. They discover it in week three, when the first real Saturday order run happens and the spreadsheet reappears next to the shop admin, quietly doing the actual work. ### Failure point one: one basket, many producers, and the pick list that does not exist A shopper fills one basket with eggs from one farm, cheese from another and apples from a third. The storefront generates one order and one packing slip. What the market needs is three producer-specific pick lists, plus one consolidated shopper basket at the pickup point, generated from the same order. The usual workaround is to tag products by producer and export the day's orders to a spreadsheet, then pivot by tag to get per-producer lines. It works for twenty orders. At a hundred orders across forty producers it becomes a manual re-export every time an order is edited, cancelled or a substitution is agreed, and the version the producer received by email on Thursday morning is no longer the version being packed on Friday. What the operation actually needs is a single order that projects two ways at once: aggregated by producer for supply, and aggregated by shopper for handover. Both views have to update from the same source when anything changes, and the producer view has to be reachable by the producer without going through the operator's inbox. ### Failure point two: variable weight. A cabbage priced per kilo cannot settle in a fixed-price cart A fixed-price cart charges at checkout. Weighed goods are only known after picking. A 1.2 kg cabbage sold at a price per kilogram means the charged amount and the final amount differ, so the platform needs to authorise an estimate at checkout and settle the real figure after weighing. Operators try three workarounds and all three leak. Selling in fixed units ("one cabbage, medium") pushes the loss onto whoever grades the produce and produces complaints about size. Selling in 100 g increments makes the shopper do arithmetic and gives you a basket of 12 x 100 g items on the pick list. Charging an estimate and refunding the difference manually means somebody reconciles refunds by hand every delivery day, and card refunds are slow and fee-bearing. The mechanic that works is an ordered quantity, an actual picked quantity, a tolerance band the shopper agrees to at checkout, and a settlement step after picking that adjusts the capture up or down within that band. That also has to flow through to the producer's payout line, because the producer is paid on what was actually supplied, not on what was ordered. ### Failure point three: stock lives on a farm, not in a warehouse, and it changes on harvest morning Warehouse inventory decrements when an item ships. Farm availability is a forecast that the grower revises the morning they pick. A market platform needs producers to declare or confirm availability per order window, not a global stock number that the operator maintains on their behalf. In a single-merchant store, only the store admin can edit stock. So the operator becomes a data entry clerk: forty phone calls or WhatsApp messages on Wednesday, forty inventory edits on Wednesday evening, and a second round of edits Friday morning when three producers report rain, a broken cooler and a smaller pick than expected. Every hour of delay between the farm's reality and the storefront's number is an hour in which shoppers buy things that do not exist. The alternative is a producer-facing availability screen tied to the current order window: open quantity, confirm quantity, mark sold out, propose a substitution. Oversell handling then becomes a defined path (short the line, refund it, offer a swap) rather than an apologetic email from the operator on delivery morning. ### Failure point four: commission, invoicing and paying forty people from one Stripe account One payment account collects one gross sum. A market has to split that sum into forty net payouts, each with its own commission rate, its own returns and shortfalls, and its own paperwork. A single-merchant storefront has no concept of a payee other than the store, so this reconciliation happens outside the software or not at all. The workaround is a monthly spreadsheet: export orders, filter by producer tag, subtract the commission, subtract the items that were short-supplied or refused at handover, add any delivery fee arrangement, then pay by bank transfer and hope nobody disputes a line. It is the single most common reason operators eventually replace the storefront, because it scales linearly with producers and it is the part where errors damage trust fastest. What the operation needs is per-producer commission rules, payout statements a producer can open and check line by line, and a clean answer to who is the seller of record for tax purposes. That last question decides whether the market invoices the shopper and pays producers as suppliers, or whether each producer invoices the shopper and the market charges a service fee. Both models are workable. Neither is expressible in a single-merchant admin. ### Failure point five and six: order windows and producer logins E-commerce is 24/7 checkout with rolling fulfilment. A market runs in cycles: orders open Monday, close Wednesday at 18:00, producers confirm Thursday, delivery or pickup happens Saturday between 09:00 and 12:00 at three locations with capped slots. The storefront has no cut-off, no cycle and no slot capacity, so operators fake it with manual open and close. The faking is where it breaks. Someone has to unpublish the shop at the cut-off and republish it after, and the one week they forget, orders land after pick lists have gone out. Delivery slots get simulated as free "products" or shipping rates with no capacity limit, so eleven people choose the 09:00 pickup at a location that can handle six. And because the producer has no login, they cannot see the window, confirm their lines, or flag a shortfall without the operator relaying messages. Giving producers their own account is not a convenience feature. It changes who owns the truth about supply. When the grower confirms what they can actually deliver, the operator stops being the bottleneck for every change, and the order that reaches the driver reflects what is really in the crate. - Market requirement: multi-seller basket. Single-merchant storefront: one order, one packing slip, per-producer split done by spreadsheet export. Multi-producer platform: one order projected as per-producer pick lists and per-shopper handover lists from the same record. - Market requirement: variable weight. Storefront: fixed price only, manual refunds. Platform: ordered vs picked quantity with post-pick settlement inside an agreed tolerance. - Market requirement: farm availability. Storefront: global stock edited by the admin. Platform: producer confirms availability per order window, with defined shortfall handling. - Market requirement: per-producer payouts. Storefront: one payout to the store, commission reconciled offline. Platform: per-producer commission rules and checkable payout statements. - Market requirement: order cycles and capped slots. Storefront: always-on checkout, manual open and close. Platform: cut-off times, confirmation phase, capacity-limited pickup and delivery slots. - Market requirement: producer access. Storefront: admin-only editing. Platform: producer login with their own catalogue, availability and payout history. ### When a single storefront is still the right call, and when to switch A single-merchant storefront is the right choice when one legal entity buys the goods, holds the stock and sells them under its own name. A box scheme that buys from farms and resells is a shop. A market where forty independent producers each sell their own goods is not, and no amount of tagging changes that. Practical signals that you have crossed the line: you are exporting orders to a spreadsheet after every cycle, you are editing stock on behalf of producers, you are calculating commission by hand, or you are answering "what do I owe you this month" from memory. Any one of those is survivable. Two or three at once means the software has stopped being the system of record and the spreadsheet has taken over, which is the state most operators are in when they start looking for alternatives. Build versus buy comes down to the same list. Everything above is buildable on top of a headless commerce stack, and it is roughly six systems of work: catalogue with producer ownership, availability by order window, weight settlement, split payouts, cycle and slot scheduling, and role-separated apps for admin, shopper, producer and driver. Plodie exists because we ran a market first, hit each of these in turn on Plodovi.hr, and concluded they were product requirements rather than edge cases. ### Key Takeaways - Single-merchant e-commerce assumes one seller, one inventory and one payout. A market breaks all three at the second producer. - The six concrete failure points are multi-seller baskets, variable-weight settlement, farm-side availability, per-producer commission and payouts, order cut-off cycles with capped slots, and producer logins. - Every workaround (product tags, spreadsheet exports, manual open and close, hand-calculated commission) scales linearly with the number of producers and fails around week three of live operation. - The switching signal is simple: if orders leave the software for a spreadsheet after every cycle, the software is no longer your system of record. - A storefront is still correct if one entity buys and resells the goods. It is wrong when producers sell under their own name. For how these requirements turn into actual screens for each role, see [One Platform, Four Apps](https://plodie.com/posts/one-platform-four-apps-how-administrator-shopper-producer-and-delivery-apps-solv), which walks an order from checkout through producer confirmation to the driver's route. ### Frequently Asked Questions #### Can't I just use a Shopify multi-vendor marketplace app instead? Multi-vendor apps solve the vendor catalogue and the commission split reasonably well, which covers two of the six failure points. They generally do not solve variable-weight settlement after picking, availability declared per order window, cut-off cycles with capacity-limited pickup slots, or the per-producer picking and handover views. If your market sells only fixed-weight packaged goods with a fixed weekly routine, an app may carry you further than a bare storefront. #### How much does it cost to set up online ordering for a farmers market? Costs split into the storefront or platform subscription, payment processing fees, and the operator hours spent on reconciliation each cycle. The third one is usually the largest and the least visible: manual pick-list exports, stock updates on behalf of producers and hand-calculated payouts are recurring labour that grows with every producer you add. Compare options on total operator hours per cycle, not on monthly licence price alone. #### Who is legally the seller when a market platform takes the payment: the market or the producer? Both models exist and the choice affects invoicing, VAT treatment and payouts. In the reseller model the market buys from producers and sells to shoppers under its own name, issuing one invoice to the shopper. In the agency model each producer is the seller of record and the market charges a service or commission fee. Decide this before you configure payments, because it determines what your payout statements and invoices must contain, and confirm the treatment with a local accountant. #### How do you handle it when a producer cannot supply what a shopper already paid for? You need a defined shortfall path rather than an ad hoc email. The common options are to short the line and refund it, offer a substitution the shopper can accept or decline before packing, or reallocate the item to another producer who has stock in the same window. Whichever you choose, the refund or adjustment has to flow through to the producer payout so nobody is paid for goods that never arrived. #### Do producers actually use a producer app, or will they keep sending messages? Adoption depends on how little the app asks them to do. A grower will open a screen that shows this week's confirmed orders and lets them tap confirm, adjust or sold out in under a minute. They will not maintain a full product catalogue with photos and descriptions. In practice operators seed the catalogue once and producers only ever touch availability, price changes and payout statements. ### Sources - [rigbyjs.com](https://www.rigbyjs.com/blog/build-multi-vendor-marketplace-on-shopify) - [checkoutlinks.com](https://checkoutlinks.com/blog/is-shopify-a-marketplace) - [shipturtle.com](https://www.shipturtle.com/blog/create-multivendor-marketplace-on-shopify) - [apps.shopify.com](https://apps.shopify.com/order-fulfillment) - [community.shopify.com](https://community.shopify.com/t/how-can-i-set-up-an-order-fulfillment-process-for-a-multi-vendor-marketplace/86552) --- ## Designing Four Apps That Feel Like One: UX Decisions Behind a Multi-Role Food Supply Chain Platform URL: https://plodie.com/posts/designing-four-apps-that-feel-like-one-ux-decisions-behind-a-multi-role-short-fo Published: 2026-08-22 · Category: Product · By: Ivan Lauc How do you design admin, shopper, producer and delivery apps that share one data model without sharing one interface? A look at the UX decisions, conflicting priorities and shared vocabulary behind a multi-role short food supply chain platform. ### Why a short food supply chain needs four interfaces, not one dashboard A short food supply chain has four roles with almost no overlapping tasks. An administrator curates a catalogue and closes order windows, a shopper browses and buys, a producer picks and packs, a driver delivers. One shared dashboard would force each role to navigate around three sets of controls they never touch, so the platform splits into four apps over one data model. The temptation with multi-sided platforms is to build a single responsive web app and hide irrelevant features behind permissions. That works when roles differ by seniority, like a manager who sees everything a clerk sees plus reports. It breaks when roles differ by context. A producer weighing courgettes in a barn at 6am and a shopper choosing a delivery slot on a sofa are not doing variations of the same job. They need different information density, different input methods and different failure states. Splitting by context also lets each app follow the conventions of its own environment. The shopper app borrows from e-commerce because that is what shoppers already know. The producer app borrows from warehouse picking tools. The delivery app borrows from courier apps. Nobody has to learn a house style invented for the sake of consistency. ### The shared vocabulary layer: one order, four vocabularies Cohesion between role-specific apps comes from a shared domain model, not shared screens. Every app refers to the same order, the same product, the same delivery window and the same producer record. What changes is the label, the level of detail and which fields are editable. The underlying identifiers never change, so a support conversation across roles stays coherent. In practice this means agreeing early on what an order actually is. On a marketplace with several producers, a shopper's single basket becomes several producer sub-orders and one or more delivery routes. If the shopper app treats that as one order, the producer app treats its slice as one order, and the delivery app treats a whole van run as one job, then support staff and users end up arguing about which number is the real one. The fix is naming each level explicitly and using that name everywhere: basket, producer order, delivery stop, route. The same discipline applies to status. A producer marking an item as packed, an administrator confirming a pickup and a driver marking a stop as delivered are all writing to the same status timeline. Each app shows only the transitions its user can trigger, but the sequence is identical underneath, which is what makes an order traceable end to end without reconciliation work. - Basket: what the shopper builds and pays for, spanning multiple producers - Producer order: the slice of a basket one producer must pick and pack - Collection or drop-off: the handover point between producer and logistics - Delivery stop: one shopper address on a route, with a time window - Route: the sequence of stops a driver works through in one run ### Resolving conflicting needs between roles Multi-role platforms hit real conflicts where one role's convenience is another's cost. Shoppers want to order late and change orders freely. Producers want early cutoffs so they can harvest and pack once. Administrators want predictability. The design job is to expose the trade-off in the interface rather than pick a winner and hide the consequences. Order cutoffs are the classic example. Rather than a fixed global deadline, the platform can let administrators configure a cutoff per delivery cycle and then make the consequences visible in every app: the shopper sees a countdown and a clear message about when the window closes, the producer sees a locked, final pick list at the moment the window closes, and the administrator sees how much revenue sits in unconfirmed baskets before the lock. Nobody is surprised by a rule they cannot see. Substitutions and shortfalls are the second recurring conflict. A producer who harvests less than expected needs a fast way to reduce a line item, but that change propagates to a shopper's paid basket and possibly to a route's load. The design pattern that works is to make the producer's action a proposal with an immediate, honest consequence shown on their own screen, for example a plain statement that reducing this quantity will refund the shopper's line and notify them. The producer sees the downstream effect before confirming, which is what keeps trust intact across the chain. ### Role-specific interface patterns that actually get used in the field Each role's environment dictates its interface pattern. Shoppers get browsing and reassurance, producers get dense lists and large tap targets, drivers get one-task-at-a-time screens usable with one hand, administrators get tables, filters and bulk actions. Designing each app for its physical context matters more than visual consistency across the four. For producers, the packing screen is the whole product. It should be sortable by the order in which items are physically stored, keep totals per product visible so a producer can harvest once for all customers rather than order by order, and work offline or on a weak signal because barns and fields rarely have good coverage. Confirmations should be one tap with an undo, not a modal asking whether you are sure. For drivers, the priority is minimising decisions while moving. A route screen that shows the next stop, the address, the customer's delivery note and a call button covers most of the job. Proof of delivery should be a photo or a single tap, and anything requiring typing belongs at the end of the run, not at the door. For administrators, the opposite is true: they work seated with a keyboard, so keyboard shortcuts, multi-select, exportable tables and edit-in-place beat any wizard. - Shopper: familiar e-commerce patterns, transparent delivery windows, clear producer attribution - Producer: aggregated pick lists, offline tolerance, large touch targets, one-tap confirmations with undo - Driver: sequential single-task screens, tap-to-navigate, lightweight proof of delivery - Administrator: dense tables, filters, bulk edits, exports and audit trails ### Keeping four apps consistent as the product evolves Consistency across four apps is maintained through shared components, a single source of truth for status and copy, and a rule that no role-specific feature ships without checking its effect on the other three. Consistency here means predictable behaviour and matching terminology, not identical layouts. A shared design system covers the primitives that genuinely repeat: product cards, quantity and unit inputs, date and delivery window pickers, status badges, empty states and error messages. Units are worth special attention in food. Selling by piece, by weight and by variable weight are three different interaction models, and if the shopper app, producer app and admin app each solve them separately, they will drift within a release or two. The other guardrail is workflow review. Before shipping a change, walk one order through all four apps and check where the change lands. Adding a shopper-facing note field means a producer has to see it while packing and a driver has to see it at the door, otherwise the feature is a promise the platform cannot keep. Most cohesion failures in multi-role platforms are not visual, they are broken hand-offs between roles that each looked fine in isolation. ### How this plays out in a real short food supply chain In a working short food supply chain, the test of the design is a single ordinary week: baskets placed, a cutoff closing, producers packing, a driver running a route, an administrator handling one shortfall and one missed delivery. If each of those steps happens in the app built for it and the order history reads as one continuous story, the four apps are functioning as one platform. Running a marketplace yourself is what surfaces the details no requirements document contains: that producers prefer to pack by product rather than by customer, that shoppers ask about delivery windows more than about prices, that drivers need the buzzer code more than the postcode. Plodie's design decisions come out of operating Plodovi.hr alongside building the software, which is why the four apps are shaped around field realities rather than an abstract role matrix. ### Key Takeaways - Split apps by user context, not by permission level: a producer packing in a field and a shopper browsing at home are not doing variations of the same job. - Cohesion comes from a shared domain model and shared vocabulary (basket, producer order, delivery stop, route), not from identical screens. - Where roles conflict, such as late orders versus early cutoffs, make the trade-off visible in every interface instead of silently favouring one role. - Match each interface to its physical environment: offline-tolerant pick lists for producers, one-hand sequential screens for drivers, dense tables and bulk actions for administrators. - Before shipping any change, walk a single order through all four apps to catch broken hand-offs, which cause most multi-role cohesion failures. For the role-by-role breakdown of what each app does and how an order moves between them, see [One Platform, Four Apps](https://plodie.com/posts/one-platform-four-apps-how-administrator-shopper-producer-and-delivery-apps-solv), which this article builds on from the design side. ### Frequently Asked Questions #### Should a multi-sided marketplace build separate apps or one app with role-based permissions? Build one app with permissions when roles differ mainly by seniority and see overlapping data, such as a clerk and a manager. Build separate apps when roles differ by context, device and physical environment, as with a farmer packing in a barn versus a shopper browsing at home. The deciding question is whether the roles share tasks, not whether they share data. #### How do you keep terminology consistent across apps for different user roles? Maintain a single glossary of domain terms tied to your data model, and treat interface copy as part of the shared design system rather than something each app writes on its own. Where a role genuinely needs a different label, map it explicitly to the canonical term so support staff and logs can translate between them. Ambiguity around the word "order" is the most common failure in marketplace platforms. #### What does a producer app need that a generic inventory app does not? Producer apps in short food supply chains need aggregated pick lists across customers, support for variable-weight items, tolerance for poor connectivity in fields and packing sheds, and a fast way to report shortfalls that automatically handles refunds and shopper notifications. Generic inventory tools assume stable stock counts and reliable network access, neither of which holds on a farm during harvest. #### How should a delivery driver app handle failed deliveries in a food supply chain? It should let a driver record a failure in one or two taps with a preset reason, capture a photo where relevant, and immediately notify the administrator and shopper so perishable goods can be redirected or rescheduled the same day. Because fresh food cannot sit in a van overnight, failed delivery handling should be designed as a same-day workflow, not an exception logged for later review. #### How do you test UX for a platform with four different user types? Test workflows end to end rather than screen by screen. Run a real order through all four roles in one session, ideally with actual producers and drivers in their own environments rather than in an office, and note every hand-off where information is lost or has to be repeated by phone. Phone calls between roles are the clearest signal of a design gap. ### Sources - [createbytes.com](https://createbytes.com/insights/designing-ux-for-multi-role-platforms) - [eleken.co](https://www.eleken.co/blog-posts/enterprise-ux) - [mozestudio.com](https://www.mozestudio.com/journal/enterprise-ux-how-to-modernize-software-in-complex-business-scenarios) - [userinterviews.com](https://www.userinterviews.com/blog/user-research-for-ux-designers) - [figr.design](https://figr.design/blog/user-experience-design-research-methods) --- ## From Spreadsheets to Software: The 6-Week Plan We Use to Migrate a Food Co-op's Order Sheets, Price Lists and Delivery Routes URL: https://plodie.com/posts/from-spreadsheets-to-software-the-6-week-migration-plan-we-use-to-move-a-food-co Published: 2026-08-21 · Category: Product · By: Ivan Lauc A week-by-week migration plan for moving a food co-operative off spreadsheets and into Plodie: what the incoming sheets look like, which columns map to which fields, the data-cleaning decisions to make before the first live order, and the parallel run that de-risks the switch. ### What a food co-op's spreadsheet system actually looks like before migration Almost every co-op we onboard arrives with the same three artefacts: a master order workbook with one tab per producer, a set of price lists sent by email as separate files, and a delivery list that lives in a phone notes app or a printed sheet in the van. Nothing is wrong with them. They just stop scaling. The detail matters more than the structure. Inside the order workbook you will typically find customer names typed three different ways ("M. Horvat", "Marija Horvat", "horvat marija"), quantities recorded in whatever unit the producer speaks in (kg for potatoes, bunch for chard, crate for tomatoes, piece for eggs), and prices that are sometimes with VAT and sometimes without depending on who sent the file. There are usually a few merged cells holding a note like "only if it rains less this week" and at least one formula pointing at a tab that was deleted last autumn. The delivery side is even more informal. Routes exist as knowledge in the coordinator's head: which village comes before which, who is never home before 17:00, which restaurant needs a delivery note signed. Migration is not just typing this into a database. It is the first time most of these rules get written down at all, which is why the first two weeks are about capture, not configuration. - Master order workbook: one tab per producer, one column per order week, customers as free text - Producer price lists: separate files or email bodies, inconsistent units and VAT treatment - Membership list: names, phone numbers, pickup point, sometimes a balance owed - Delivery information: route order, access notes and cut-off exceptions held informally - Shadow copies: a private sheet kept by a member who does the invoicing ### The 6-week migration plan, week by week The plan runs six weeks because a co-op's real unit of time is the order cycle, not the calendar. Six weeks gives you roughly four to six order cycles: two to observe and extract the rules, two to load and test data, one to run in parallel, and one to operate live with support still on hand. Nothing in the plan requires the co-op to pause trading. Order weeks continue in the spreadsheet exactly as before until week five. That constraint shapes everything else, because it means data extraction has to happen against a moving target and every export gets re-pulled shortly before go-live. - Week 1: Discovery. Walk one full order cycle with the coordinator, from opening the sheet to closing the van door. Collect every file, including the ones nobody officially uses. Write down the cut-off times, the delivery days and the exceptions. - Week 2: Data cleaning decisions. Agree the unit list, VAT treatment per producer, minimum order quantities, pickup points and delivery zones. This is a decision week, not a typing week, and it needs the person who does the invoicing in the room. - Week 3: Load producers and products. Producer records, product catalogue, units, prices, availability windows, per-producer VAT rate. Producers receive their own Producer app logins and are asked to confirm their own catalogue. - Week 4: Load customers and delivery structure. Deduplicated members and business buyers, pickup points, delivery zones and route order, plus one test order pushed end to end through the Administrator, Producer and Delivery apps. - Week 5: Parallel run. One real order cycle entered in both the spreadsheet and Plodie. Compare totals per producer, per customer and per route before anything ships. - Week 6: Live cycle, sheet archived. The co-op runs the cycle in Plodie only. The old workbook is set read-only and kept as a reference, not as a working file. ### Which spreadsheet columns map to which fields in the Administrator app Mapping is usually a one-to-many exercise: a single spreadsheet column often has to be split across two or three structured fields, because a sheet stores everything as text and a platform stores products, units, prices and tax separately. The mapping itself is straightforward once the co-op has decided how it wants to describe things. The recurring hard cases are units and price. A cell reading "kelj 2 veze 4€" contains a product, a quantity, a unit and a total price, and the unit price has to be derived. Similarly, a producer who writes "crate" needs the crate defined as a sellable unit with a stated weight, or shoppers will not know what they are buying and the delivery driver will not know what to count. We resolve these with the producer, never by guessing, because the producer is the one who has to pick and pack against that definition afterwards. - Producer tab name → Producer record (legal name, contact, VAT status, payout details) - Product row label → Product name + category + unit of measure (kg, piece, bunch, crate, litre) - Price cell → Unit price + VAT rate + whether the entered price is gross or net - "Min 5kg" note in a comment → Minimum order quantity on the product - "Only May to July" → Availability window / seasonal on-off on the product - Customer name column → Deduplicated customer record with pickup point or delivery address - Quantity cell → Order line with quantity and unit, tied to the order cycle - Route notes → Delivery zone, stop sequence and per-stop delivery instructions ### The data-cleaning decisions that must be made before the first live order Four decisions have to be closed before a co-op can take a real order in software: unit normalisation, VAT handling per producer, minimum order quantities, and one canonical customer record per buyer. Every one of them is a business decision belonging to the co-op, not a technical setting, and deferring them simply moves the pain into the live week. Unit normalisation is the biggest. A bunch of chard is a legitimate selling unit, but it must be defined consistently so pricing, picking and invoicing agree. We keep the producer's natural unit wherever we can and attach an indicative weight to it, rather than forcing everything into kilograms and losing how the producer actually works. Crates and mixed boxes get defined explicitly, with contents listed. VAT is the one that causes real money problems if it is skipped. In a typical co-op some producers are inside the VAT system and some are below the registration threshold, which means the same tomato from two farms is invoiced differently. Each producer gets a VAT status and each product a rate, and we always confirm whether the price the co-op has been quoting members is gross or net. Customer deduplication comes last and is mostly mechanical: merge the three spellings, keep one record, attach the history, and agree that new members are created in the platform only. ### Giving producers their own logins instead of emailing an updated sheet The single biggest workload change for a co-op coordinator is that producers stop sending price lists and start maintaining their own catalogue. Each producer gets a Producer app login, sees their own products, updates availability and prices before the cut-off, and receives their picking list for the cycle without anyone re-typing anything. Onboarding producers takes patience and works best as a phone call plus a one-page printout, not an email with a link. We seed each producer's catalogue from their last price list so they log in to something familiar rather than an empty screen, then ask them to correct it. The first ask is small: confirm what is available this week. Price editing and seasonal windows come in the second or third cycle. Expect a spread of adoption. In practice a co-op ends up with producers who update their own availability weekly, and one or two who still phone the coordinator. That is fine, and the platform should accommodate it: the coordinator can update a producer's availability on their behalf, so a low-tech producer never becomes a reason to keep the spreadsheet alive. ### Failure modes we have seen, and how to handle each Migrations rarely fail on data. They fail on habits and on the one person or producer who never made the transition. The parallel run in week five exists precisely to surface these while the spreadsheet is still there as a safety net, and the fixes are organisational as often as they are technical. The most common is the shadow sheet: a member who keeps a private copy "just for the invoicing" and quietly becomes a second source of truth. It usually appears because the platform did not yet produce a report that person needed. The fix is to find out what the private sheet does that the software does not, add or export that view, and then agree a date when the copy stops being maintained. The second is the unreachable producer before Friday cut-off. Handle it with a default rule agreed in advance rather than a scramble: either carry forward last week's availability, or mark the producer unavailable automatically if they have not confirmed, and tell every producer which rule applies to them. Whichever you choose, the co-op should never have to guess on Friday afternoon. - Shadow spreadsheet kept by a member → identify the missing report, build or export it, set a stop date - Producer unreachable before cut-off → pre-agreed default (carry forward or auto-unavailable) plus a coordinator override - Customers who order by phone or WhatsApp → coordinator enters orders on their behalf; keep the channel, move the record - Unit disputes at delivery ("that is not a crate") → indicative weights on every non-standard unit, printed on the picking list - Historic member balances → migrate as opening balances in week 4, reconciled against the old sheet during the parallel run - Coordinator becomes the only trained user → train a second person during the parallel week, not after go-live ### Key Takeaways - Budget six weeks, measured in order cycles, not calendar days: discovery, data decisions, catalogue load, customer and route load, one parallel cycle, then live. - The hard work is deciding, not typing: unit normalisation, VAT status per producer, minimum order quantities and one canonical customer record must be settled before the first live order. - Map columns to structured fields deliberately. A single cell like "kelj 2 veze 4€" hides a product, quantity, unit and a price that may or may not include VAT. - Give producers their own logins with a pre-seeded catalogue so they confirm rather than create, and let the coordinator update availability for the ones who still prefer a phone call. - Run one full order cycle in the spreadsheet and the platform side by side. It costs one week and catches shadow sheets, unit disputes and cut-off gaps before they cost real deliveries. For a closer look at where all this data ends up once the migration is finished, see [One Platform, Four Apps](https://plodie.com/posts/one-platform-four-apps-how-administrator-shopper-producer-and-delivery-apps-solv), which walks through how the Administrator, Shopper, Producer and Delivery roles each handle a single order. ### Frequently Asked Questions #### How long does it take to move a food co-op off spreadsheets? Plan for around six weeks, because the real constraint is the number of order cycles you can observe and test against rather than the amount of data to load. A co-op with a weekly cycle gets roughly four to six cycles in that window, which is enough for discovery, loading, one parallel run and one supported live week. Co-ops with fortnightly cycles usually need eight to ten weeks for the same number of rehearsals. #### Do we have to stop taking orders during the migration? No. The plan is built so the co-op keeps trading in its spreadsheet right up to the parallel week. Data extracted early is re-pulled shortly before go-live so nothing entered in the meantime is lost, and only the final week runs on the platform alone. #### What happens to our historical order data and member balances? Historical order lines are usually kept as an archived read-only copy of the old workbook rather than imported line by line, because past text-based records rarely map cleanly onto structured products and units. What does get migrated is anything still operationally live: member records, contact details, pickup points, producer catalogues and any outstanding balances, which are loaded as opening balances and reconciled during the parallel run. #### What if some of our producers are not comfortable with apps? Assume a mixed group and design for it. Producers who want to manage their own availability and prices get a Producer app login with their catalogue already seeded from their last price list, and those who prefer to phone or message the coordinator keep doing that while the coordinator records the update. A low-tech producer should never be a reason to keep a parallel spreadsheet running. #### Can a small co-op with only a handful of producers justify moving off spreadsheets? The trigger is usually complexity rather than size. A co-op with six producers, two pickup points and consistent units can run on a sheet for a long time, but once you add per-producer VAT differences, minimum order quantities, seasonal availability and a delivery route with sequencing, the manual re-typing and reconciliation start costing more hours per week than the migration itself. ### Sources - [caspio.com](https://www.caspio.com/blog/excel-to-web-data-migration-best-practices/) - [analytix.com](https://www.analytix.com/blog/top-5-data-cleaning-techniques) - [montecarlo.ai](https://montecarlo.ai/blog-data-cleaning-techniques) - [apxml.com](https://apxml.com/courses/intro-etl-pipelines/chapter-3-the-transformation-stage/data-cleaning-correcting-errors) - [tamr.com](https://www.tamr.com/blog/5-data-cleaning-techniques) --- ## One Platform, Four Apps: How Admin, Shopper, Producer and Delivery Roles Each Get Their Own Workflow URL: https://plodie.com/posts/one-platform-four-apps-how-administrator-shopper-producer-and-delivery-apps-solv Published: 2026-08-15 · Category: Product · By: Ivan Lauc A role-by-role breakdown of how a short food supply chain platform splits into four connected apps for administrators, shoppers, producers and drivers, and how an order moves between them. ### Why one app cannot serve all four SFSC roles A short food supply chain has four distinct roles with conflicting needs: an administrator coordinating the whole cycle, a shopper buying food, a producer managing stock and prices, and a driver executing routes. Each works in a different place, at a different time, on a different device, so one shared interface serves none of them well. The conflict is easy to see once you map the day. A producer updates availability at 6am from a field, often on a phone with patchy signal, and needs to enter quantities in the units they harvest in. A shopper browses in the evening on a couch and wants photos, filters and a checkout that takes under a minute. An administrator opens a laptop mid-morning to see whether the order window closes with enough volume to justify a route. A driver wants one screen: next stop, what to hand over, proof it happened. Generic e-commerce tools solve the shopper and stop there. Farm management tools solve the producer and stop there. What gets lost in both cases is the connective tissue: the moment an order line becomes a picking task, and the moment a picking task becomes a delivery stop. That handoff is where most local food operations lose hours to spreadsheets, phone calls and messaging groups. ### The Administrator app: running the order cycle, not chasing it The administrator app is the control room of the supply chain. It defines order windows, approves producers and their listings, sets commissions and delivery zones, consolidates incoming orders into per producer pick lists, builds routes, and resolves the exceptions that inevitably appear between order close and dispatch. Most of an SFSC coordinator's week is spent on a repeating cycle: open the ordering window, watch volume accumulate, close it, split orders by producer, tell each producer what to bring and when, group deliveries geographically, then reconcile what was actually delivered against what was ordered and paid for. Done manually, each step is a spreadsheet export and a round of messages. Done in software, closing the window automatically generates every producer's pick list and every driver's route from the same order data. The exception handling matters as much as the happy path. A producer delivers 8 kg instead of the 10 kg ordered. Someone cancels after the cutoff. A pickup point closes for the day. The administrator app is where those decisions get made once and then propagate: the shopper sees an adjusted order and refund, the producer sees the corrected quantity in their settlement, and the driver's manifest updates before they load the van. - Catalogue and producer onboarding: approvals, categories, units, VAT rules - Order window management: open, close, cutoff reminders, minimum order thresholds - Order consolidation: one shopper basket split into per producer pick lists automatically - Logistics setup: pickup points, delivery zones, time slots, route grouping - Financial layer: commissions, producer settlements, invoices, payout reports - Exception handling: substitutions, shortfalls, cancellations, partial refunds ### The Shopper app: buying from many producers in one basket The shopper app has one job: make buying from ten small producers feel like buying from one shop. A single basket, one checkout, one delivery or pickup choice, one invoice, and clear visibility of who grew each item and when the next order window closes. Local food buying has constraints that ordinary e-commerce does not. Availability is seasonal and often changes daily. Quantities are variable, so a shopper ordering 1 kg of tomatoes may receive 0.95 kg and needs to understand how that is priced. Delivery is not next day everywhere, it is Thursday afternoon to a specific pickup point. A shopper app built for SFSC surfaces those constraints instead of hiding them: a countdown to the cutoff, a producer name and location on each product card, and a clear statement of when and where the order arrives. Retention in local food comes from rhythm rather than promotions. Repeat ordering features carry the weight here: reorder from last week's basket, a saved standard basket, subscription boxes, and notifications when a favourite producer lists something new. The shopper app should also close the loop after delivery with an order history that shows exactly which farm each item came from, which is the material that makes the traceability story real rather than a marketing line. ### The Producer app: stock, prices and pick lists from the field The producer app lets a farmer publish what they actually have, at the price they set, and receive a consolidated pick list when the window closes. It is designed for phone use in the field: a few taps to update quantities, set a price, mark an item out of stock, and confirm what has been packed. The most common failure in local food platforms is asking producers to maintain a catalogue like an online retailer. They will not. A workable producer app separates the slow moving part, product definitions with photos, units and descriptions set up once, from the fast moving part, this week's available quantity and price. Updating availability should take under a minute per product, with bulk actions for a whole category and the ability to copy last week's setup. After the cutoff, the app flips from selling to fulfilment. The producer sees one aggregated list: 14 kg of potatoes, 22 lettuces, 9 jars of honey, split by delivery day if needed, with labels or crate tags where the operation uses them. They confirm packed quantities, flag any shortfall, and that confirmation is the signal the administrator and driver need. Settlement records build from the same confirmations, so the producer can see what they are owed without asking anyone. - Product library: photos, description, unit of measure, pricing rules, set up once - Weekly availability: quantities and prices per order window, copy from last week - Order visibility: live view of what has sold before the window closes - Pick list: aggregated quantities per window, per delivery day, per drop point - Packed confirmation: report actual quantities, flag shortfalls and substitutions - Settlements: sold value, commission, payout history ### The Delivery app: routes, handovers and proof of delivery The delivery app turns the day's orders into an ordered list of stops with everything the driver needs at each one: address, contact, time slot, items to hand over, items to collect, and a way to record what happened. It works offline and syncs when signal returns, because rural routes lose coverage. Local food delivery is not parcel delivery. A single run often includes collection legs at farms, a consolidation stop at a hub, drops at pickup points, and home deliveries in a narrow window. Crates and cool boxes go out and come back. Some customers pay on delivery. The app has to model a route as a sequence of mixed actions rather than a flat list of drop offs, and it has to let the driver reorder or reschedule when a customer is not home. Proof of delivery is what makes the rest of the system trustworthy. A photo, a signature, or a scanned code at each stop creates the record that resolves disputes later and closes the order in the administrator app. When a driver marks a stop as failed, the shopper is notified and the administrator sees it in the exception queue immediately, rather than discovering it the next morning from a complaint. ### Following one order through all four apps The value of role-specific apps is in the handoffs. A single order touches all four in sequence: the shopper places it, the system splits it by producer, the producer packs against a pick list, the driver collects and delivers, and the administrator settles the money. Each step writes data the next step reads, with no re-entry. A concrete walk-through makes the pattern clear. On Monday a producer sets 30 kg of tomatoes available at a given price. On Tuesday evening a shopper adds 2 kg to a basket that also contains bread from a bakery and cheese from a dairy, then picks a Thursday pickup point. On Wednesday at noon the window closes and the administrator app generates three pick lists, one per producer, plus a route covering two farm collections and four pickup points. On Thursday morning each producer confirms packed quantities, the tomato grower reporting 1.9 kg instead of 2 kg. That adjustment recalculates the shopper's total and the producer's settlement automatically. The driver collects, delivers, records proof at each stop, and the order closes. Every party sees the same version of events. That is the core argument for four connected apps rather than one general tool plus a group chat. The information a role needs is the information a different role already entered. Plodie is built on exactly this structure, four role-specific apps over one shared data model, because the coordination cost between roles is usually the thing that limits how large a short food supply chain can grow. ### Key Takeaways - Short food supply chains have four operational roles with genuinely different needs: coordination, buying, stock and pricing, and logistics. - The administrator app runs the order cycle: windows, consolidation into pick lists, routes, settlements and exceptions. - The producer app must be fast enough to use from a field, separating a one-time product library from weekly availability and prices. - The shopper app makes a multi-producer basket feel like one shop, with order windows, pickup points and traceability made explicit. - The delivery app handles mixed collection and drop routes with offline support and proof of delivery that closes the loop back to admin. These workflows come from running a real short food supply chain ourselves, described in [how our own SFSC, Plodovi.hr, drives our innovation](https://plodie.com/posts/building-better-SFSCs-through-experience-collaboration-and-technology). ### Frequently Asked Questions #### Do I need all four apps to start a short food supply chain? No. Many operations start with the shopper and producer apps plus an administrator back office, and handle delivery manually while volumes are small. The delivery app becomes worth adopting once routes involve multiple collections, several pickup points and more than one driver, because that is when paper manifests start causing errors. #### What is the difference between SFSC software and a normal e-commerce webshop? A webshop assumes one seller with fixed stock and next-day shipping. SFSC software assumes many independent producers, availability that changes weekly, order windows with cutoffs, baskets that must be split into per-producer pick lists, and delivery to time-slotted pickup points. It also handles producer settlements and commissions, which a standard webshop does not. #### How do producers who are not comfortable with technology use a producer app? The design target is a phone, a few taps and no typing where possible. Product definitions are set up once, often with help during onboarding, and the weekly task is limited to adjusting quantities and prices, usually with a copy-from-last-week option. Operations that succeed also give producers a person to call during their first two or three cycles. #### Can a food hub, cooperative or county-level project use the same platform as a single farm? Yes, because the difference is mostly in the administrator role. A single farm selling direct uses producer and shopper functionality with a light admin layer, while a hub or cooperative uses the full administrator app to onboard many producers, consolidate orders and manage shared logistics. The shopper and delivery experiences stay the same in both cases. #### What happens when a producer cannot deliver the full quantity ordered? The producer flags the shortfall when confirming packed quantities. The system recalculates the shopper's total and issues a partial refund or credit, updates the driver's manifest before loading, and adjusts the producer's settlement. The administrator sees the exception in a queue and can offer a substitution instead if the operation allows it. ### Sources - [news.wisc.edu](https://news.wisc.edu/demand-for-local-food-challenges-distribution-systems-report-finds/) - [aces.edu](https://www.aces.edu/blog/topics/farm-management/introduction-to-farm-to-customer-sales-software/) - [pmc.ncbi.nlm.nih.gov](https://pmc.ncbi.nlm.nih.gov/articles/PMC12031551/) - [ids.ac.uk](https://www.ids.ac.uk/projects/enhancing-effectiveness-of-multi-stakeholder-platforms-in-food-and-agriculture/) - [brookings.edu](https://www.brookings.edu/articles/the-potential-and-pitfalls-of-the-digitalization-of-americas-food-system/) --- ## How our own SFSC Plodovi.hr Drives our Innovation: Building Better SFSCs Through Experience, Collaboration, and Technology URL: https://plodie.com/posts/building-better-SFSCs-through-experience-collaboration-and-technology Published: 2025-01-02 · Category: SFSC · By: Plodovi.hr Plodovi.hr isn’t just a marketplace; it’s a hub for innovation and collaboration, working to make short food supply chains more sustainable, efficient, and successful for everyone involved. Together with our partners, we’re building the future of local food systems and paving a way that others can follow. At Plodie, we’re not just developing software for short food supply chains (SFSCs)—we’re actively running one ourselves. This daily hands-on experience gives us a deep understanding of the challenges and opportunities faced by every member of the chain, from farmers and producers to logistics providers and end consumers. It’s this real-world engagement that allows us to create tailored, high-quality solutions and drive meaningful improvements across the board. ![A classic plodovi.hr basket] ### Turning Challenges into Software Solutions By operating our own SFSC, we’re able to identify and address pain points in real time. Whether it’s optimizing delivery logistics, improving supplier communication, or enhancing customer experience, our software development is guided by the real-world demands of a working SFSC. This ensures that our technology is not only functional but also finely tuned to the unique needs of short food supply chains. ![Ivan and Igor working on our Saas platform] ### Learning and Growing Together with Our Partners One of the most rewarding aspects of our journey is partnering with other SFSCs that use our technology. These collaborations create a dynamic feedback loop where we learn from each other’s experiences. Our partners often highlight areas where our software can be improved or suggest new features that would make a significant difference in their operations. We gladly embrace these ideas and integrate them into our SaaS platform, knowing that we all share the same goal: creating the best software and business expertise to kickstart or scale SFSCs. Beyond software, we also exchange valuable insights on business operations, helping each other refine processes and adopt best practices. ![An image of the full plodie and plodovi team] ### Exploring New Revenue Streams and Business Models with Our SFSC At Plodovi.hr, we leverage our own SFSC as a testing ground for innovative revenue streams and business models, constantly finding new ways to expand our impact and add value for our producers and customers. Here's how we're doing it: - Catering with Local Flavor: We’ve launched a catering service that exclusively uses local products from our producers, serving weddings, receptions, and various events with the freshest and most authentic ingredients. Click on the post to watch the video and see how our catering comes together :) - Corporate Gift Boxes: Each year, we design and market corporate gift boxes filled with locally sourced products to companies on both local and national levels. - Expanded Delivery Solutions: For areas beyond our delivery range, we’ve partnered with third-party delivery services to ensure seamless service and reach. ![This is how we pack our orders delivered through our third party delivery services] - B2B Partnerships: We collaborate with restaurants, hotels, and other local businesses, offering them a tailored B2B solution. To meet their unique needs, we’ve developed specific functionalities within our SaaS platform. - Pop-Up Bars with Local Products: We organize exclusive pop-up bars at parties and events, featuring only local products, providing a unique experience for attendees. - Farmers’ Markets and Fairs: We regularly participate in farmers’ markets and trade fairs, where we showcase, present, and sell products from our network of producers. - Green Public Procurement Pilot Projects: In partnership with local governments and public institutions, we’re developing a pilot project to integrate green public procurement practices, supporting sustainability and local agriculture. These initiatives not only generate additional revenue but also allow us to test innovative business models and refine our platform to better serve the needs of SFSCs worldwide. ### A Playground for Innovation Our involvement in the day-to-day operations of Plodovi.hr isn’t just about solving immediate problems—it’s about creating a space for innovation. This “playground” allows us to test, refine, and perfect solutions that others can adopt with confidence. At the same time, the partnerships we foster help us expand our knowledge and continually evolve, ensuring that our technology and business procedures stay ahead of the curve. Plodovi.hr isn’t just a marketplace; it’s a hub for innovation and collaboration, working to make short food supply chains more sustainable, efficient, and successful for everyone involved. Together with our partners, we’re building the future of local food systems and paving a way that others can follow. --- ## Pilot Project AJMO LOKALNO Presented URL: https://plodie.com/posts/Pilot-Project-AJMO-LOKALNO-Presented Published: 2024-12-16 · Category: News · By: Plodovi.hr Launched at the initiative of Šibenik-Knin County, the pilot project Ajmo Lokalno proposes an innovative business model for short supply chains, which will connect local food producers, restaurateurs, and end consumers through a digital platform and app of the same name. The public presentation of the pilot project "Ajmo Lokalno: Branding the Šibenik-Knin County as a Destination for Sustainable Tourism, Recognizable Gastronomy, and Local Food Production" took place at the Krka-Kistanje Rural Business Incubator on the 12th of December 2024. The "[Ajmo Lokalno](https://ajmolokalno.hr/)" pilot project was designed to create an innovative business model for short supply chains that connects local producers, restaurateurs, and end consumers through a digital platform and app. The focus is on developing a mechanism for the more efficient and sustainable distribution of local food, along with a network for education, experience exchange, and knowledge transfer. The goal is to revalorize local food production and further develop the Šibenik-Knin County brand as a destination for high-quality, diverse local food, recognizable culinary heritage, and sustainable tourism. Our collaboration with this Short Food Supply Chain, the first to be owned by the local government, represents a pivotal step forward. Once they reach self-sufficiency, this project will serve as a pioneering case study, paving the way for the establishment of numerous public-sector-driven SFSCs across the region and beyond. What was presented at the launch? - Inspiring stakeholder stories – Attendees met several initial stakeholders of the Ajmo Lokalno network, including farmers, fishermen, restaurateurs, and winemakers, who shared their challenges and the potential of local food production. - Lectures by top experts:Dr. Irena Ateljević and Tomislav Škarica, project executors from the Terra Meera Center for Human Potential and Sustainable Development, introduced the project to the public. - Prof. Dr. Marija Heffer, Head of the Department of Medical Biology at the University of Osijek, delivered a presentation titled “Ajmo Zdravo,” discussing the impact of modern food systems on nutrition and health. - Mg. Roman Ozimec, an expert in agro-biodiversity, highlighted the importance of inventorying and cataloging local varieties, breeds, and authentic gastronomic products to preserve biodiversity and create an authentic gastrotourism offering. - Ivan Lauc, Director of Plodie, demonstrated the innovative digital platform for managing short supply chains, which serves as the technological backbone for the future online marketplace "ajmolokalno.hr." - Panel discussion – Stakeholders from the "Ajmo Lokalno" network shared the current challenges and opportunities for producers and restaurateurs. - Prize draw and tasting – Three gift boxes filled with local products were awarded to lucky winners of the prize draw. - Culinary delights – Chef Dino Bebić prepared a feast using ingredients and products from local producers. --- ## Plodie showcased at Americas Food & Beverage Show & Conference in Miami USA URL: https://plodie.com/posts/Plodie-showcased-at-Americas-Food-and-Beverage-Show-and-Conference-in-Miami-USA Published: 2024-09-25 · Category: News · By: Plodovi.hr It was an honor to be selected as one of four companies from Europe to attend the joint internationalization mission to Miami, USA. Want to hear more? From September 16 to 18, we had the opportunity to attend [America’s Food & Beverage Show & Conference](https://www.americasfoodandbeverage.com/) in Miami, USA. We were selected as one of four European companies to attend the joint mission to Miami. At the conference, we connected with various government organizations, such as USDA representatives from Wisconsin, New York, and Colorado, as well as Spanish government organizations focused on supporting farmers, along with producers from Central and South America. This experience gave us a deeper insight into international markets and a much greater understanding of the U.S. market, which differs significantly from the European one. It was also a pleasure to meet other small and medium-sized enterprises from Europe on this joint internationalization mission in the U.S.: - Biohifas from Lithuania - DeFoodExchange from Poland - #SANSEVERA ([https://sansevera.pl](https://sansevera.pl)) from Poland We also had the chance to meet Vanessa Aflalo one of the owners of [Green Tomato Market](https://www.greentomatomarket.com/), a platform similar to ours in Osijek, which likewise helps small producers sell their products online. From them, we learned that subscription boxes of seasonal fruits and vegetables are the most popular in the U.S., whereas ordering specific items, common in Europe, is not a typical practice. We were delighted to taste exotic tropical fruits at the “[Robert is Here](https://www.robertishere.com/)” stand, which were nothing short of extraordinary, especially for our Slavonian taste buds. We got to know the Moehling family, the stand's owners, who introduced us to various previously unknown fruits, such as jackfruit, monstera (fruit), pitaya, papaya, Thai bananas, and more. It was fascinating to meet a small producer engaged in farming since 1959 right in the heart of a metropolitan area like Miami. We’re still full of impressions, new knowledge, connections, and hope! Funded by the European Union. The views and opinions expressed are those of the author and do not necessarily reflect the official stance of the European Union. --- ## Our first conference on Short Food Supply Chains URL: https://plodie.com/posts/our-first-conference-on-short-food-supply-chains Published: 2024-05-27 · Category: News · By: Plodovi.hr The first-ever KLOnference gathered short supply chains, experts, and public sector leaders in Osijek-Baranja County to spark collaboration, share innovations, and champion local producers. Dive into this vibrant mix of ideas and solutions for a sustainable future! Organized by the Osijek-based online marketplace Plodovi.hr, and under the auspices of the National Rural Network, the KLOnference (KLO is short for SFSC in Croatian) brought together six Short Food Supply Chains (SFSC) from across Croatia, regional government representatives, and sectoral experts. Those present at Hotel Lug on May 16 and 17 attended engaging lectures and learned about programs and opportunities under the Common Agricultural Policy (CAP), as well as the European Innovation Partnership programs. The conference was warmly opened by Ivan Lauc, director of the Osijek online marketplace Plodovi.hr. Following him on stage was Roman Ozimec, President of the Croatian Biospeleological Society and the Society for Research and Conservation of Biological Diversity in Croatia ([ADIPA](http://adipa.hr/)). His compelling lecture on the Inventory of Agro-Biodiversity and the Cataloging of Traditional Agricultural Products posed a significant open question: Why don’t other regions follow Varaždin County's example in branding their traditional products? ![Visitors entering the conference. Our natural accreditations are visible] Dr. Irena Ateljević from [Terra Meera](https://www.terrameera.com/) presented the potentials and benefits of regenerative agriculture, while Dr. Marija Heffer delivered an impactful lecture highlighting numerous shortcomings and the unsustainability of the modern food system. She emphasized the critical role of small producers as key stakeholders in the supply chain. The six SFSCs showcased were: [Plodovi.hr](https://plodovi.hr/) from Osijek, [Growtovchani.com](https://growtovchani.com/) from Križevci, [Putujuce.com](https://www.facebook.com/groups/564900001060276/) from the Neretva Valley, Sikirevčanka d.o.o. from Sikirevci, [Međimurski štacun](https://www.facebook.com/medimurskistacun) from Međimurje, and [E-selo.hr](https://e-selo.hr/) from Pula. On the first day, representatives of each supply chain shared their challenges, needs, and opportunities encountered in their operations. On the second day, they exchanged experiences in an interactive discussion at the first roundtable. ![An image of our first roundtable with four Short Food Supply Chain founders] The second roundtable brought together members of the public sector: Romeo Jukić, Head of Agriculture for Osijek-Baranja County; Magdalena Parat, Head of Agriculture for Vukovar-Srijem County; Josip Nikolić, Mayor of Sikirevci; Zdenko Podolar, Director of Vukovar AgroCluster; and the previously mentioned Ivan Lauc, Director of Plodovi.hr. The discussion focused on current and potential future collaborations between the public sector and short supply chains, particularly in the context of green public procurement. ![An image of our second roundtable with public representatives] Ivan Lauc, Director of Reducos Software j.d.o.o.—the company behind the technology used by three online marketplaces in Croatia (Growtovchani.com, E-selo.hr, and Plodovi.hr)—introduced technology specifically developed for the needs of SSCs, continuously improved over the past four years. ![An image of the audience on our conference] The KLOnference centered on pressing SFSC issues and new CAP opportunities that the EU will offer in the upcoming programming period. The focus was on intervention 77.03, "Support for EIP Operational Groups," which aims to foster cooperation, link research and agricultural practices, and enhance the exchange of information about existing and new processes, presented by Ivan Lauc. Valentina Hažić, owner of a business consulting firm, presented intervention 77.04, "Support for Short Supply Chains and Local Markets," alongside the successfully implemented 16.4.1 project from the previous programming period. She played a key role in launching what is now known as Međimurski štacun. The conclusion of the KLOnference is clear: only through joint efforts and targeted initiatives can small Croatian producers and short supply chains be saved. This was the first event of its kind in Osijek-Baranja County, but judging by the program's quality, it certainly won’t be the last. All lectures were recorded and will be available on the [@plodovi](https://www.youtube.com/@plodovi) YouTube channel. ![Our attendees enjoying our exclusively local catering] European Innovation Partnerships and public awareness of the potential beneficiaries regarding the results of the Program and opportunities within the CAP Strategic Plan are key horizontal themes of the program. (CO)FINANCED BY THE EUROPEAN UNION. EUROPEAN AGRICULTURAL FUND FOR RURAL DEVELOPMENT: EUROPE INVESTS IN RURAL AREAS Measure: Technical Assistance – Sub-measure 20.2: "Support for the establishment and management of the National Rural Network" --- ## Applying New Agricultural Software in the Age of Short Food Supply Chains (SFSC) URL: https://plodie.com/posts/Applying-New-Agricultural-Software-in-the-Age-of-Short-Food-Supply-Chains Published: 2024-03-23 · Category: SFSC · By: Plodovi.hr Discover how innovative Short Food Supply Chain (SFSC) software empowers farmers by simplifying the journey from farm to table, eliminating middlemen, and fostering a more direct connection with consumers. In the modern world, agriculture is undergoing a significant transformation. With technological advancements reshaping every aspect of the farming process, farmers can now leverage new tools to increase sales. These tools can also help them digitalize their business and build stronger customer connections. One of the most impactful changes is the rise of Short Food Supply Chains (SFSC). This means making the process of getting food from farmers to consumers shorter and with fewer steps in between. The goal is to connect them more directly. This blog will explore how integrating new software technologies like Plodie into modern farming practices can digitalize your produce business. Moreover, we will dive into how adopting SFSC principles can help you reach local markets, increase profitability, and ensure sustainability in your agricultural business. ### What Are Short Food Supply Chains (SFSC)? Understanding the core concept of Short Food Supply Chains (SFSC) is important before diving into the specifics. At its core, SFSCs are systems where food moves from farmers to people, with as few middlemen as possible, to build local food networks. This model contrasts with traditional, longer supply chains that involve multiple middlemen (distributors, wholesalers, retailers), which add cost, complexity, and environmental impact. SFSCs are gaining traction as people become more interested in knowing where their food comes from, how it’s grown, and supporting local farmers. Examples of SFSC include: - Farmers Markets: Direct sales from producers to consumers. - Farm-to-Table Programs: Restaurants sourcing food directly from local farms. - E-commerce platforms: They connect local farmers with buyers, allowing consumers to order fresh produce directly from farms. [Plodovi.hr](http://plodovi.hr), [growtovchani.com](http://growtovchani.com), and [e-selo.hr](http://e-selo.hr) are good examples of such SFSCs. These direct connections between farmers and customers help build trust and create sustainable local food systems. When small food producers work alone, their reach and resources are limited. They struggle to compete with larger companies or to reach enough customers. But if they join forces in a short food supply chain, they can share resources, combine their reach, improve their offering and attract more customers together. Here’s why: - Bigger Reach: Customers like to buy from markets that offer a variety of fresh, local products. A group of producers can create that kind of market together, attracting more people. - Lower Costs: By sharing things like delivery, packaging, or marketing, they reduce expenses for everyone. - Stronger Together: When producers promote the community as a whole, everyone benefits. A customer drawn by one product might also buy from others in the group. Simple Example: Think of a farmers' market. Each farmer selling alone might get a few customers, but together, the market becomes a destination where hundreds of people come to shop. It’s the power of working together! As demand for fresh, high-quality, locally grown food rises, Short Food Supply Chains (SFSCs) offer significant advantages. They are environmentally friendly by reducing transportation and waste, while also supporting small-scale farmers by providing them direct access to local markets, higher profits, and greater control over pricing. SFSCs strengthen local economies, promote sustainable practices, and foster closer connections between customers and producers. ### New Software Technology in Modern Farming #### E-Commerce and Digital Marketplaces One of the most significant ways technology transforms farming is through e-commerce platforms connecting producers directly with consumers. Those platforms allow farmers to sell their crops online, removing the need for traditional retail intermediaries, brick-and-mortar shops, marketplaces, or other sales channels. Digital marketplaces specifically designed for agricultural products are growing in popularity and give farmers a direct route to local buyers. For instance, an online platform can provide a space where local customers can browse and purchase fresh products, meat, or dairy from their area. This can drastically reduce the costs associated with distribution and marketing, allowing farmers to sell directly to consumers at competitive prices. #### How to Digitalize Your Crop Selling Business Digitalizing your business is essential for staying competitive in modern agriculture. Below are first steps you can take to incorporate new technologies into your business and capitalize on the benefits of SFSCs. ### Adopt an E-Commerce Platform The journey to digitalization begins with establishing a strong online presence. This includes creating a website and setting up social media profiles. This serves as an essential tool to help consumers: - Learn more about your farm - Browse your available products - Place orders conveniently For those looking to accelerate this process, several platforms are designed to help farmers create online stores and list their products in a user-friendly way – giving them a head start in building their online presence. Examples include: - [Plodovi](https://plodovi.hr) - [Growtovchani](https://growtovchani.com) - [E-selo](https://e-selo.hr) But the one thing all these platforms have in common is their backend usage of Plodie - A field-tested, customizable, plug-and-play solution. Plodie simplifies every aspect of e-commerce in agriculture, from building a professional website to managing sales and logistics efficiently. #### Things you can do with Plodie: There are four apps within Plodie software and each app is specifically designed to cater to the needs of its link in a Short Food Supply Chain. Administrator app Gives you full control over your short food supply chain. Keeps your customers happy. Provides easy-to-use customization, automation, and enhanced sales functionality. Administrators can provide technical support to all users and can be permitted to execute actions in the name of any user regarding deliveries, user inquiries and information. Some of its features are: - Automated accounting - Inventory management - Pickup locations - Controlling producer rates - Delivery regions, days & prices - Routing engine Shopper app Is specifically made for customers who can order from multiple producers and expect products in a single package for delivery or pickup. They can also order fresh local products harvested and delivered from various producers on the same day. - Direct contact with admin and producer - Real-time overview of operations - Automatization of all orders The delivery app focuses on the word "minimal"— minimal kilometers, time in transport, carbon footprint, and food waste. Our algorithm efficiently calculates deliveries and trips to producers. Delivery users also have an option to leave notes to admin for producers and admin users. - Changeable payments on the spot - Carbon efficient deliveries - Real-time overview of operations Producer app gives you a complete solution for producer operations in SFSCs.You have full control over your producer profile and product offerings. It even gives you an overview of upcoming and past orders with revenue statistics and automated accounting. - Direct contact with admin and producer - SFSC specific functionalities - Automatization of all orders #### Real-life digitalization examples For example, if you grow vegetables, you can offer subscription-based delivery services or allow customers to order baskets of seasonal produce. You can also join the growing trend of online farmers’ markets, where you connect directly with consumers in your local community. Many producers and farmers chose this option and changed up their advertising strategy as well. Selling your products online pairs perfectly with effective social media marketing. Social media platforms, such as Facebook, with their vast and diverse audiences, make it easier than ever to showcase your products to the right people. With the right strategy, you can turn casual browsers into loyal customers! By digitalizing your sales process, you can build a more robust customer base and avoid relying on traditional intermediaries. The Role of SFSC in Digitalizing Agriculture Digitalization allows you to cut down on distribution costs, enhance productivity, and directly connect with consumers. Whether you are selling through an online marketplace or offering farm-to-table services, technology can help you optimize your operations and grow your customer base. As the world becomes increasingly focused on sustainability, people are actively seeking out locally grown, responsibly produced food. By digitalizing your business and adopting SFSC principles, you not only meet these consumer demands but surpass expectations and position yourself for long-term success in an evolving market. ### Conclusion New software technologies like Plodie and the principles of Short Food Supply Chains (SFSC) are shaping the future of agriculture. You can increase operational efficiency, enhance profitability, and build strong, direct relationships with your local consumers. Whether you leverage e-commerce platforms or not, the digital tools available today can definitely help you thrive in the modern agricultural landscape. By integrating SFSC practices you can ensure that your farm is not only competitive but also a key player in the future of sustainable agriculture. And of course, bring fresh locally sourced food to the tables of many families! --- ## Why the Future Lies in Local Food and Short Supply Chains URL: https://plodie.com/posts/why-the-future-lies-in-local-food-and-short-supply-chains Published: 2024-01-17 · Category: SFSC · By: Plodovi.hr How to increase food quality by encouraging local production and how to distribute locally produced food to customers efficiently. The future leans toward short food supply chains for several reasons, with benefits spanning environmental, economic, and social dimensions. Here’s why short supply chains are gaining importance: - Reduced Environmental Impact: Local food production and shorter supply chains cut down on the need for long-haul transportation, which reduces fuel consumption, carbon emissions, and pollution. By decreasing the distance food travels from farm to plate, short supply chains can contribute significantly to environmental sustainability. - Fresher, Healthier Food: Shorter supply chains mean that food reaches consumers faster, often allowing it to be sold at peak freshness and nutritional value. This reduces the need for preservatives or other processes designed to extend shelf life, meaning consumers enjoy higher-quality, fresher produce. - Stronger Local Economies: By supporting local farms and businesses, short supply chains help keep money within communities, which can boost local economies. When people buy locally produced food, they directly support small-scale farmers and food producers, creating a more resilient and self-sustaining local economy. - Enhanced Food Security and Resilience: Short supply chains help communities be less reliant on global supply networks, which can be vulnerable to disruptions like those seen during the COVID-19 pandemic. With more locally sourced food, communities are better equipped to withstand crises that could disrupt international supply chains. - Reduced Food Waste: Locally sourced food is often distributed more efficiently, with fewer opportunities for spoilage in transit or storage. Since the food doesn’t need to travel as far or stay fresh for as long, it can be picked and sold closer to ripeness, reducing waste both during production and in consumers' homes. - Better Transparency and Trust: Short supply chains foster a direct relationship between producers and consumers, which can build trust and ensure greater transparency about farming practices. Consumers can often trace where their food comes from, gaining insight into the production process and supporting farmers whose practices align with their values. - Innovation and Adaptation: Shorter supply chains encourage local producers to innovate, producing more specialized or diverse crops that appeal to local tastes. With fewer intermediaries, producers can respond to market changes and customer preferences more quickly, increasing the variety and quality of food options. These benefits make short food supply chains an increasingly attractive model for the future, offering sustainability, resilience, and quality that align with the needs of modern consumers and the challenges facing our food systems. --- # Contributing ## Writing for Plodie URL: https://plodie.com/contribute Pitch an article to Plodie: what we publish about growing, short food supply chains and delivery, the criteria a submission has to meet, and how to send it. Plodie builds software for short food supply chains, and we run one ourselves through Plodovi.hr. That means our readers are cooperative organisers, growers, small producers and the people driving the vans — not a general audience who need the idea of local food explained to them. So we would rather publish one honest account of a season that did not go to plan than another overview of why local is better. If you have done the work, you already have the article. Topics: Growing & regenerative practice, Short food supply chains, Delivery & last-mile logistics, Eco produce & certification, Running a cooperative. ### What a submission has to meet - **Written from the field.** Something you grew, moved, sold or organised. We want the decision you would take back, not a summary of good practice. - **1,000 – 2,000 words.** Long enough to say something concrete, short enough to stay useful. If the idea needs 800 words, send 800. - **Specific.** Yields, prices, distances, spoilage rates, hours. A season with numbers in it is worth ten without. - **Original and exclusive.** Not published anywhere else, and it stays that way. Link to it, quote it, or republish an excerpt with a canonical link back. - **Sourced.** Research, regulation and statistics need a link to the primary source. Health and nutrition claims are regulated in the EU, and we hold them to that. - **Written by you.** Use AI to research or tighten your prose if it helps. An article generated wholesale by a model reads like one, and we will spot it. ### Saving us both the time - Link-building filler — an article written around an anchor text rather than around an idea. - Product pitches in disguise, whether the product is an agri-input, a machine or a piece of software. - Anything already published on your own site, Medium or LinkedIn. - Superfood listicles, and round-ups of methods you have not used yourself. - Unsourced health or nutrition claims. In the EU these are regulated, and we will not carry them. - Eco and sustainability claims with nothing behind them — say what was certified, by whom, and to which standard. - Paid placements. We do not sell articles or links, at any price. ### The ones we always get **Do you pay for articles?** Not at the moment. What you get is a proper edit, your byline, a followed link and distribution to an audience that works in this every day. If we commission something specifically, we agree a fee up front. **Can I write in Croatian?** Yes. Send the draft in Croatian and we will work through the English version with you before anything is published. Nothing goes out in your name that you have not read. **Can I link to my farm or cooperative?** Yes, where it is relevant to the point you are making, and once more in your author bio. What we will not run is an article whose shape exists to justify the link. **Can I republish it myself afterwards?** After 30 days, as long as the canonical link points back to the version on plodie.com. An excerpt with a link is fine at any time. **I have an idea but no outline yet.** Send the idea and say so in the outline field. If it is a good fit we will help you shape it before you write a word. --- # Legal ## Terms of use URL: https://plodie.com/terms-of-use ### Terms of Use Any use of this website is subject to the terms and conditions outlined below. These terms of use apply to all visitors to the website. Users are required to familiarize themselves with the Terms of Use of the website www.superznalacosijek.hr before using the website. If they have any additional questions or uncertainties regarding the terms of use, they can contact us via the contact form or the contact information available on our website. The website is managed by the teaching company Plodie (hereinafter referred to as: Plodie, We, Us, Our). By using this website, users are deemed to be aware of, fully understand, and accept these Terms of Use of the website at all times, including particularly the Privacy Policy, which regulates and details the provisions regarding data processing and cookie rules. By using the content of the Plodie website, the user accepts all possible risks arising from the use of this website and agrees to use the content solely for non-commercial purposes for informational purposes and at their own risk. If there is a contractual relationship between Plodie and the user, then in accordance with the contractual terms. ### Terms of Use and Disclaimer Plodie fully disclaims any responsibility that may arise from or be related to the use of this website, for any actions by users who use or misuse the content of this website, and for any damage that may occur to the user or any third party in connection with the use or misuse of the content of this website. Plodie reserves the right to change the content of the website at any time and without prior notice and is not responsible for any damage caused by such changes. Plodie is not responsible for any consequences caused by changes in content. Plodie strives to maintain all functionalities of the website but cannot guarantee that all functionalities will always be available, nor is it responsible for any unavailability of the site, nor for any damage that might arise due to interruptions in availability, non-publication, deletion of content, or errors in the operation of the site. Information on the website is informational, and Plodie reserves the right to change or discontinue any content on the portal without prior notice. Plodie cannot be held responsible for any damage caused by the use of any part of the content. Plodie is not responsible for the content or availability of other websites to which it links. Additionally, Plodie is not responsible for any damage caused by typographical errors. ### Intellectual Property All content on our website, including but not limited to texts, photographs, graphics, artwork, trademarks or signs, brands, logos, videos, sounds, music, user interfaces, and code (collectively "Content"), as well as the appearance and presentation of the Content, is owned by Plodie or our licensors and is protected by copyright and related rights, trademark rights, design rights, sui generis database rights, and other intellectual property rights. Documents, data, and information published on our website may not be reproduced, distributed, or otherwise used for commercial purposes without the express consent of Plodie or in any manner that may cause harm to Plodie or any third party. Nothing on our website and in these Terms of Use should be construed as granting any license or rights to use any part of the "Content." Users have the right to link to the Plodie website from other websites or social media, except in cases where it is done with the intent to harm Plodie, fraudulently, or to misuse any part of the "Content" on this website. By using and visiting the website, you acknowledge and are warned that Plodie will use all possible and permissible legal remedies to protect its intellectual property rights. The website may contain links to other companies' websites, social media platforms, mobile applications, and other products and services (such as third-party advertising) ("third-party platforms"). Plodie has no control over such third-party platforms, does not necessarily endorse them, and assumes no responsibility for them, including their content, accuracy, or functionality. Plodie is not responsible for the legality of content, management of websites to which you link from the Plodie website. We strive to make the use of our website and the Internet in general safe, so we would appreciate it if you notify us of any illegal or immoral content on websites you have accessed or that are linked to the Plodie website. ### Final Provisions This website is tailored for users accessing the site within the Republic of Croatia and may not be suitable for use elsewhere. If you access our website from another territory, you are responsible for complying with all applicable laws and regulations. We reserve the right to change these Terms at our discretion at any time. We may, but are not obligated to, notify you in advance. You are responsible for regularly reading these Terms. --- ## Privacy Policy URL: https://plodie.com/privacy-policy Regulation (EU) 2016/679 of the European Parliament and Council of April 27, 2016, on the protection of individuals with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (hereinafter: General Regulation). Plodie is committed to protecting your privacy, which is based on the General Regulation and its principles, and in accordance with the above, adopts this Privacy Policy. This Privacy Policy governs how Plodie collects, uses, and manages your data, including personal data, if you are a user of our services, a supplier, a partner, or have simply subscribed to our promotional materials (hereinafter: You). This Policy applies only to natural persons (data subjects) or their personal data. The processing of information concerning legal entities (such as information considered as trade secrets, professional secrets, and confidential information) is not covered by this Policy. Plodie is the Data Controller in relation to the personal data we collect from you, i.e., the entity that determines the purposes and means of processing personal data. Please read this Policy carefully to understand why and how we collect your information and how we use it. By using our website or contacting us through the contact form, you consent to the use of your personal data in the manner described in this Policy. This Privacy Policy will be regularly reviewed and may be updated or amended at any time. Any amended version will be published on this website, and any such policy change will take effect immediately upon publication unless otherwise specified in the amendment. By registering or continuing to use this website, you confirm your knowledge and consent to the processing of data in accordance with the amended or updated version of this Policy. ### Personal Data For the purposes of this Privacy Policy, the term Personal Data refers to any data relating to an identified or identifiable natural person whose identity is or may be determined – the data subject. Therefore, this includes any data that directly identifies a natural person or through which a natural person can be identified, such as name, surname, address, personal identification number (OIB), address, email, and IP address. Identification can be direct through the data themselves or in connection with any other information in our possession or which might come into such possession. Except where otherwise specified in this Privacy Notice, the terms used here have the meanings given to them in REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT AND COUNCIL of April 27, 2016, on the protection of individuals with regard to the processing of personal data and on the free movement of such data and repealing Directive 95/46/EC (General Data Protection Regulation or GDPR). ### Data Controller Plodie (we, us, or our) acts as the Data Controller regarding the processing of your Personal Data covered by this Privacy Policy in terms of applicable data protection regulations. This means that Plodie determines how these Personal Data are processed and for what purposes. ### Types of Personal Data Processed and Processing Purposes Visiting and browsing the Website does not require user registration, so your registration and account data are not collected. For more information on data collection via cookies, please refer to our Cookie Notice. Plodie, in accordance with this Privacy Policy, may collect the following personal data: - Data from voluntarily completed contact forms on our website by users for the purpose of making inquiries or communicating with Plodie; - Other data that the user voluntarily provides to Plodie when requesting a particular service or providing certain information. When you access the website, general, non-personal data (number of visits, average time of visit, pages visited) are automatically recorded. We use this information to measure the attractiveness of our website and to improve its content and usability. ### Legal Basis for Processing Personal Data Plodie does not collect or process your personal data except when you provide consent, or when there is a legal basis for collecting personal data or a legitimate interest of Plodie in processing. This Privacy Policy does not apply to personal data collected without internet access or otherwise, including through third-party websites or personal data collected and processed by franchises related to Plodie or Plodie. ### Retention of Personal Data All personal data processed by Plodie based on an individual's consent or legitimate interest will be retained permanently until the individual's consent is withdrawn, i.e., until a request for cessation of processing. Plodie deletes this data before the cessation of consent by the individual only if the purpose of processing personal data has been fulfilled or if required by law. Plodie does not transfer your personal data to unauthorized third parties. ### Security Statement Plodie takes all necessary measures to ensure the security of your personal data and strives to protect it from loss, destruction, falsification, manipulation, unauthorized access, or unauthorized disclosure. ### Persons with Access to Your Data Access to your data is granted solely to authorized representatives of Plodie who are familiar with the policies and procedures for protecting your data. Third parties may access and process your personal data only in the situations described below: - Third-party service providers who, on behalf of and for Plodie, provide certain services and products, such as accounting firms, our legal representatives, partners maintaining technical infrastructure, etc. In this case, they process your personal data strictly according to our instructions, and we provide them only with the data necessary to provide their services. These service providers are obligated to maintain confidentiality within the agreed relationship and to implement organizational and technical protection measures. - When Plodie is obligated to submit your data to competent authorities (e.g., Ministry of Finance, tax administration) in accordance with applicable regulations to provide services within its business subject. - Competent authorities during the supervision of the legality of our business and conduct, in which case your personal data are processed in accordance with their legal authorities. ### Website Analytics – Google Analytics Our website may use Google Analytics, a web analytics service provided by a third party, Alphabet Inc. and its subsidiaries (Google). The information generated by the cookie about your use of this website (including your IP address) will be transmitted to Google and stored on servers in the Republic of Ireland, where it will be stored for up to 26 months and then deleted (subject to the terms and conditions applicable on the date of this policy). Google will use this information to evaluate your use of the website, compile reports on website activity for website operators, and provide other services related to website activity and internet usage. Google may also transfer this information to third parties if required by law or if such third parties process data on behalf of Google. Google will not associate your IP address with other data held by Google. Additional information about Google’s privacy policy can be found at http://www.google.com/privacy.html ### Rights of Individuals in Relation to the Processing of Personal Data To ensure lawful processing of personal data, as an individual under applicable data protection regulations, you have the following rights: ### Right to Access Personal Data You have the right to request confirmation of whether Plodie is processing your data and, if so, you also have the right to access it. You have the right to access your personal data that we process about you and can request detailed information, particularly regarding its processing purposes, type/categories of personal data being processed, including access to your personal data, recipients or categories of recipients, and the intended period for which the personal data will be stored. Access to personal data may be restricted only in cases prescribed by Union or national law or when such restriction respects the essence of fundamental rights and freedoms of others. ### Right to Rectification If you believe that Plodie is using incorrect or incomplete data, or if you wish to change your data, as an individual, you have the right to supplement incomplete data, modify and correct it, taking into account the purposes of processing. Please note that it is necessary to specify what is not correct, complete, or updated and in what sense the above needs to be corrected and provide the necessary documentation supporting your claims. ### Right to Erasure (Right to be Deleted) This is your personal right to request Plodie to delete personal data concerning you without undue delay, and the Data Controller must delete the personal data without undue delay. You have the right to request the deletion of personal data concerning you if one of the following conditions is met: - Your personal data are no longer necessary for the purposes for which we collected or processed them; - You have withdrawn consent on which the processing is based in accordance with Article 6(1)(a) or Article 9(2)(a) and there is no other legal basis for processing; - You have objected to the processing of your personal data in accordance with Article 21(1) of the General Data Protection Regulation and there are no overriding legitimate grounds for processing; - The personal data have been unlawfully processed; - The personal data must be erased to comply with a legal obligation under Union or Member State law to which the Data Controller is subject; - The personal data were collected in relation to the offer of information society services referred to in Article 8(1). ### Right to Restriction of Processing: You have the right to request Plodie to restrict the processing of your data if you believe that Plodie holds inaccurate data; if the processing is unlawful, but you do not want your data to be erased, rather to be used for restricted purposes; Plodie no longer needs your personal data, but you need it for the establishment, exercise, or defense of legal claims; you have objected to processing while verification of whether the legitimate grounds of the Data Controller override yours is pending. ### Right to Data Portability: You have the right to receive the personal data concerning you, which you have provided to the Data Controller, in a structured, commonly used, and machine-readable format. Furthermore, you have the right to transmit this information to another controller without hindrance from Plodie. ### Right to Object When personal data are processed for marketing purposes, you have the right to object at any time to the processing of personal data concerning you for such purposes; if you object to processing for direct marketing purposes, the data will no longer be processed for those purposes. ### Right to Lodge a Complaint with a Supervisory Authority: This is your personal right to lodge a complaint with a supervisory authority, in the country where you live, work, or where the alleged infringement occurred, if you believe that the processing of personal data concerning you infringes data protection rules. For the territory of the Republic of Croatia, the supervisory authority for Plodie is the Croatian Personal Data Protection Agency, located at: Selska cesta 136, 10000 Zagreb, Croatia, website:http://azop.hr/, tel.: +385 1 4609 000. ### Notification to the Supervisory Authority of a Personal Data Breach If a breach of this Privacy Policy occurs, Plodie is obliged to notify the competent authority. When there is a suspicion that a criminal offense has been committed due to the breach of rights, Plodie is obligated to notify the police and/or the competent state attorney about the breach. ### Right to Withdraw Consent This is your personal right to withdraw your consent for the processing of data based on the same. Regarding the withdrawal of consent for the processing of your personal data for cookies as mentioned above, please refer to our Cookie Notice. Please be aware that in certain cases provided by law, we may not be able to fully comply with your requests to exercise your rights, e.g., to fulfill our legal obligations, or for the purpose of establishing, exercising, or defending legal claims, we may need to retain certain of your Personal Data even after you have requested deletion. ### Changes to This Privacy Policy If we change how we handle your Personal Data concerning your use of our platform, we will update this Privacy Notice. We reserve the right to change our practices and this Privacy Notice at any time, so we encourage you to review the Privacy Notice frequently to be informed about any updates and changes to this Notice. ### Contact Information for the Data Controller To ask questions or comment on this Privacy Policy and our data protection practices or to file a complaint about our compliance with applicable data protection regulations, please contact us via email at reducos.software@gmail.com. We will acknowledge and investigate any complaints about how we manage Personal Data (including complaints that we have violated your rights under applicable data protection regulations).