Food costs are volatile. A single ingredient like tomatoes, chicken, or oil can double or triple in a month. Menu prices move slowly; costs move weekly. The math is genuinely hard to do by hand: a dish's cost flows from its recipe, which flows from preps like sauces and doughs, which flow from ingredients, which flow from invoice line items in mixed units that have to be converted to the units a recipe actually uses.
Restaurant owners are cooks and operators, not analysts. Existing tools were built for multi-unit chains, not the single-location owner. So most independents run blind, and a dish can sell below its production cost for months before anyone notices.
Smaller to mid-size restaurants first: single location, owner-operated, a few suppliers, dozens to a couple hundred menu items. The same engine generalizes to any business that buys inputs and sells products, but restaurants come first.
On affordability and simplicity, not enterprise feature depth. If using Tapd takes more effort than snapping a photo of an invoice, it won't get used, so that's the bar every feature has to clear.
George kept asking himself the same thing about Greek Bites' menu: is this dish still making money, or did an ingredient price creep past the point where it's not? He had no fast way to actually check.
So he built one himself: a margin calculator workbook, by hand, mapping every dish back to its ingredients and their prices. It worked, but keeping it current meant re-entering every price change manually.
Noah joined to turn George's spreadsheet into real software: read invoices automatically, keep every price in history, and never show a margin that wasn't honestly earned. That's Tapd today.
Tapd started in Greek Bites' kitchen. Our co-founder George runs the restaurant, and our co-founder Noah builds the product. Every feature ships to Greek Bites first, in a real kitchen, before it ships to anyone else.
See it in action