Inventory Management Software For Restaurant

You buy a case of tomatoes, you store kilograms, you sell a portion. Nothing else in inventory software has to survive that. It is why generic stock tools fail in kitchens and why restaurant inventory products are their own category despite looking superficially similar.

We sell source code you clone and run yourself, so there is nothing here to log into. For most restaurants the answer is a dedicated product or a well-built spreadsheet, and this page is about knowing which.

Theoretical versus actual is the whole discipline

The number that matters is not how much stock you have. It is the gap between how much you should have used and how much you did.

That third step is why implementations stall. Mapping every dish to quantities of every ingredient, including yields, is genuinely laborious, and a product that has not had it done is a product nobody uses. When evaluating anything in this category, ask how the recipe data gets in and how long it takes, because that is the actual project.

Yield is the detail that makes recipes wrong

A kilogram of purchased onions is not a kilogram of usable onion. Trim, peel, bone, and shrinkage during cooking all change the quantity, and a recipe costed on purchase weight will understate food cost consistently.

Any product worth buying handles a yield percentage between purchase unit and usable unit. It is a small field with a large effect, and it is one of the fastest ways to tell a serious tool from a stock counter with a restaurant theme.

What else the category has to handle

Spreadsheets, honestly

A single site with a stable menu can run this on a spreadsheet, and plenty do. The workable version has a sheet per storage area, a recipe sheet with yields, and a weekly count. It takes discipline rather than software.

It stops working at a second site, because consolidating counts and prices across locations by hand is where errors enter, and at a menu that changes often, because recipe maintenance becomes the bottleneck.

When a restaurant business builds

Not for a single restaurant. The build case is a group or a supplier building something the products do not cover: central production kitchens where one site manufactures for others, franchise operations where head office needs visibility without owning each site's system, or a distributor giving customers a portal into their own ordering.

Each of those is a multi-tenant problem before it is an inventory problem.

What you would start from here

There is no inventory in this stack. No products, no stock, no recipes, no yields, no counts, no supplier invoices, and no till integration.

What the Vault template provides for the group or franchise case is the layer around it: organizations so each site or franchisee is isolated, roles and invitations so a site manager sees their own storeroom while head office sees all of them, a Hono backend with Prisma and Kysely on Postgres, an admin app, and Stripe billing if you charge sites for access.

You would write the product, unit conversion, recipe, and count models, the variance calculation described above, and the integration with whichever till system provides sales. Unit conversion is the piece to model carefully at the start: purchase unit, storage unit, and recipe unit with a yield between them, because retrofitting that into a schema that assumed one unit is a rewrite.

If you run one restaurant, a dedicated product or a disciplined spreadsheet will beat anything you build. The packs below are for the multi-site case.