Guides

A launch checklist for a meal delivery service

The items below are ordered by how expensive they become once customers exist. Everything near the top is nearly free to decide now and requires a conversation with every customer to change later.

Decide before the first customer

  1. What a plan is

    Meals per week, delivery days, term length, and whether it ends or renews. Keep the set small — every extra tier multiplies the rules you support permanently.

  2. Where the cut-off sits

    Worked backwards from your longest supplier lead time plus planning hours. Publish it on the plan page rather than burying it in terms.

  3. Pause and skip rules

    Extend the term or forfeit the days. Either is defensible; changing it after customers rely on it is not.

  4. How you capture location

    Insist on a map pin at signup. This is the single most expensive field to retrofit and the one that causes the most day-to-day loss.

  5. How allergens are recorded

    Structured fields, separated from preferences. Retrofitting structure onto free text means re-contacting everybody.

  6. Your service area

    Deliberately, including which areas you will serve only on specific days. Set by accumulation, it becomes an unprofitable tail.

Safe to defer

  • Software

    While the model is still moving, a spreadsheet is more flexible. Buy once the structure has settled and the coordination cost has not.

  • Menu breadth

    A small rotating set is easier to cost, buy for and cook well. Breadth is a later luxury.

  • Multiple plan tiers

    Start with one or two. Adding is easy; removing a tier customers are on is not.

  • Automation

    Understand the manual process first. Automating a process you have not run is how you automate the wrong thing.

Run the first two weeks deliberately over-resourced

The first fortnight is where you discover what your process actually is, and it is worth carrying more hands than the volume justifies to have the attention available.

Specifically, check the first delivery to every new customer rather than treating it as routine. The address is untested, the allergen record has never been exercised, and the customer has no basis for assuming a problem is unusual — which makes an early failure disproportionately likely to end the relationship.

Write down what you did

Whatever you decide about cut-offs, pauses and service area, record it somewhere durable. Founders hold this in their heads and it works until the second person joins, at which point undocumented rules become inconsistently applied ones.

It also makes an eventual migration to software far simpler, because the questions the setup will ask are exactly the ones you have already answered.

Common questions

What is most expensive to change after launch?
Structured allergen data and precise delivery locations. Both require going back to every existing customer, and until they exist the automatic safety and routing checks cannot run at all.
Should a new meal business buy software before launching?
Usually not. While plan structure and menu format are still changing, a spreadsheet is more flexible, and automating a process you have not yet run tends to automate the wrong thing.
How many plans should a new service offer?
One or two. Adding a tier later is straightforward; removing one that customers are already on is a conversation with each of them, and every extra tier multiplies your operational rules.
Why check the first delivery to each customer?
Because the address, the allergen record and the whole chain are untested, and a new customer has no history to judge whether a problem is unusual. Early failures end relationships disproportionately often.

See how this works in practice

The home page walks through the same mechanics against a real admin loaded with a demonstration kitchen: production, packing, routes and the customer side.