The Tuesday Night Declaration: How Producers Post Next Week's Availability in Under Four Minutes, and the Six Rules That Keep the Numbers Honest

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.

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.