The weekly rhythm of running a meal subscription

Every meal subscription runs the same underlying cycle: selections open, selections close, purchasing commits, production runs, boxes go out, exceptions get resolved, and the whole thing repeats. Operators who have not made that shape explicit still live inside it — they just experience it as a series of surprises.

Writing it down is unglamorous and changes the business more than most software does, because it moves decisions from the moment they become urgent to the moment they are cheap.

Three things get dramatically more expensive if deferred. An empty selection slot costs nothing before the cut-off and produces either an unwanted default or a missing box afterwards. An allergen conflict costs a substitution before cooking and a discarded portion after. A failed delivery costs a redelivery on the day and an argument a week later.

Everything else — pricing reviews, menu changes, service-area decisions — genuinely can wait for a monthly pass, and treating them as urgent is how operators end up with no time for the three that are.

At twenty customers one person holds the rhythm in their head and it works. Somewhere in the low hundreds — earlier if customers change plans often — it stops fitting, and the tell is not volume but the first week nobody is confident the production sheet matches what customers actually ordered.

At that point the useful move is not to work the rhythm harder but to remove steps from it: let customers pause themselves, derive production from selections rather than maintaining it, and let terms expire without anybody noticing they should.

That is also the honest answer to when software becomes worth buying. Not at a meal count — at the point where the coordination between steps has become the job.