The Data-Entry Tax in Restaurant Software

We build one of these. This piece is about the failure mode of our own category, and it's the one nobody puts in a sales deck.

The tax, quantified

That's the tax: the work sits entirely up front, and the payoff sits entirely at the end. Any interruption — a busy fortnight, a staff departure, a broken walk-in — lands squarely in the gap, and the project is quietly over.

Why week three specifically

1. 1.Week 1 — enthusiasm. The demo was convincing and you enter thirty ingredients in one sitting.
2. 2.Week 2 — the tedium becomes visible. You're a third of the way in and nothing works yet, because a partial dataset produces no valid numbers at all.
3. 3.Week 3 — something urgent happens. It always does. The half-built system produces nothing, so nothing is lost by stopping.
4. 4.Week 8 — you cancel, and reasonably conclude that costing software doesn't work for a restaurant your size.

The ongoing tax, which is the one that actually kills it

Setup is finite. Maintenance isn't. If keeping the tool current means retyping supplier prices every week, you've bought a spreadsheet with a subscription — and it will go stale for exactly the reasons a spreadsheet does. See software vs. a spreadsheet.

The last row is the honest one: the deciding never goes away, and shouldn't. Everything above it is the tax.

Five questions to ask any vendor

1. 1.How long until I see one real number? If the answer involves weeks, that's the tax. Ask for hours.
2. 2.What do I have to type in, and what comes in automatically? Be specific: menu, ingredients, prices, yields, sales.
3. 3.What happens when a supplier price changes — do I enter it? This is the question that predicts abandonment better than any other.
4. 4.What does the tool show me when my data is incomplete? The right answer is “it tells you it's incomplete.”
5. 5.Can I export everything, including on the way out? A tool holding your recipe data hostage is a tool you can never leave.

What we do about it, and where we don't

Marji's answer to setup is a photograph: your menu is digitised and costed in about a minute, so the first useful number arrives before the tedium does. Invoices come in the same way, which removes most of the weekly maintenance, and an approved price change goes back to a linked POS item rather than being retyped — the Square version of that workflow is here.

Where we don't escape it: yields still need your judgement, AI still misreads a line sometimes, and a dish with no recipe still needs one built. We flag low-confidence reads for a one-tap fix rather than quietly guessing — which is slower than pretending, and it's the only version we'd defend.

The general point stands regardless of which tool you pick: judge costing software on time-to-first-number and on weekly maintenance, not on its feature list. The feature lists are all similar. The tax is what differs, and it's what decides whether you're still using it in March.

Time-to-first-number is the one you can test before you buy. What recipe costing software actually has to do sets out the four jobs — unit conversion, yield, recosting, turning a cost back into a price — with one plate costed line by line, so you can check the arithmetic against a dish you already know the answer to.