Guides
Building it yourself versus buying it
Plenty of meal-plan operators have a developer in the family or a technical co-founder, and the first version genuinely does take a few weekends. The cost is almost entirely in what comes after.
The first version is not the expensive part
A customer list, a weekly selection screen and a production total are a fortnight of work for a competent developer. That is why so many kitchens have one — the initial build is genuinely tractable, and it fits the business perfectly because it was written for it.
What accumulates afterwards is the edge cases: a pause that has to reduce purchasing, a plan change mid-cycle, a term that must expire on its own, an allergen check against a meal that was auto-assigned, a driver whose round changed after the sheet was generated.
Each is small. Collectively they are the product, and they arrive one urgent Tuesday at a time — usually while the person who wrote the original is doing something else.
The costs that are usually left out of the estimate
Maintenance, permanently
Dependencies age, hosting changes, browsers break things. This is not a project cost; it is an ongoing obligation with no end date.
The bus factor
One person understands it. When they are unavailable, an urgent fix waits — and a meal business runs on a daily deadline.
Correctness under change
Making one customer change propagate atomically to five downstream views is the genuinely hard engineering, and it is where home-built systems most often turn out to be subtly wrong.
Auth, roles and data protection
Home addresses and health information carry obligations. Getting access control right is real work that produces no visible feature.
Opportunity cost
The founder-hours spent on it are the scarcest input the business has.
When building is genuinely the right decision
Three cases, and we would say so rather than pretend otherwise. If your operating model is genuinely unusual — a structure no product models — a bespoke system may fit where nothing off the shelf does.
If you already employ developers with spare capacity and the system is strategically core rather than incidental, the calculus changes; you are buying control rather than saving money.
And if your requirements are genuinely small — a dozen customers, one delivery day, no pausing — a spreadsheet or a tiny script is proportionate, and buying software is over-engineering.
The honest middle answer
Most kitchens that build end up with something that handles the happy path well and the exceptions poorly, and then keep a spreadsheet alongside it for the exceptions. That is the worst configuration available: the maintenance burden of software with the reconciliation burden of a sheet.
If you are going to build, be honest that the exceptions are the product and budget for them. If you are not, the useful question is not which system has more features but which one propagates a change correctly — because that is the part that is hard to write and easy to get subtly wrong.
Common questions
- How long does it take to build a basic meal-plan system?
- A customer list, selection screen and production totals are perhaps a fortnight for a competent developer. The remaining years go on exceptions — pauses reducing purchasing, terms expiring, allergen checks on auto-assigned meals.
- When is building genuinely better than buying?
- When your operating model is genuinely unusual, when you already employ developers and the system is strategically core, or when your requirements are small enough that a script is proportionate.
- What is the most underestimated cost?
- Correctness under change. Making one customer amendment propagate atomically to production, purchasing, labels, delivery and billing is the hard engineering, and home-built systems are most often subtly wrong there.
- What is the worst outcome?
- A built system that handles the happy path plus a spreadsheet alongside it for exceptions. That combines the maintenance burden of software with the reconciliation burden of a sheet.
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.
Related reading
- GuidesHow to choose meal delivery softwareMost software evaluations start with a feature comparison, which is the wrong end. Start from where your current week breaks, because that is what you are actually buying a fix for.
- GuidesDo you actually need meal delivery software?We sell this software, so treat what follows accordingly — but the honest answer for a meaningful number of kitchens is not yet, and buying early tends to end with the spreadsheet running alongside the system.
- GuidesSpreadsheets vs meal delivery softwareThis comparison is usually written by software vendors and is usually unfair. Spreadsheets are excellent at several things software is bad at, and there is exactly one thing they cannot do.
- SolutionsMeal delivery software for subscription kitchensMost software sold to food businesses is built for one-off orders. A meal-plan kitchen sells a commitment that runs for weeks, and almost every operational problem it has comes from that difference.