An Advanced Excel Sheet: A Lean ERP for a Small Sausage Maker

A small meat-products company I worked with was planning its entire sausage production in one Excel workbook, looked after by one technologist. Orders came in by the kilogram, every recipe was built around a fixed batch size, and every ingredient arrived in lots bought on different dates at different prices. Whenever an order changed or a new one came in, the whole thing had to be recalculated by hand, and in a small food business that happens a lot. What they asked for wasn't an ERP. They wanted the logic of that workbook, just made reliable: take the day's orders and tell me what to produce, what's missing, what to buy and roughly how much it will cost. One user, one desktop, and something that would carry them for about a year until a bigger system made sense. I like to call the result an advanced Excel sheet, because that's the right size for it. ## Why not just buy an ERP? That was my first question too, so before writing any code I went through what they could buy. Full ERP suites are built for companies with an IT department, and for one technologist and 8 products most of that weight is overhead you pay for every month. Odoo came the closest, since it treats recipes as bills of materials, scales them to the order and tracks lots and expiry dates. But getting it there takes weeks of configuration, often with a paid consultant, and it scales recipes to the exact order instead of forcing a full batch. Order 7 kg of a 10 kg recipe and Odoo will happily calculate 0.7 of a batch, which is simply the wrong answer for a sausage maker. The lighter tools for small manufacturers, like MRPeasy and Katana, are easier to start with, but some of them still route you through a sales representative for onboarding and setup, and the pricing gets harder to predict once you add users or modules. Some Katana users have reported price increases of 300 to 400 percent after their first subscription period. The option I liked most was Odoo's Community Edition, which is open source, so if you want full control you can run it on your own server and only pay for hosting. The setup work doesn't go away, though, so in the end I kept the workbook's logic and built a small system around it. ## One plan for the whole day The technologist enters all of the day's orders together as a single production plan, and each order gets rounded up to a full batch. If a recipe is built for 30 kg and a customer orders 50 kg, the plan makes 60 kg, and the extra 10 kg goes into finished-goods stock, where it's offered against the next order for the same product. The recipes then turn those batches into ingredients (meat and fat in kilograms, spices in small fractions of a kilogram, casings in metres), and everything is added up across the whole plan, so instead of one calculation per order the technologist sees one combined list for the day. ## Stock that knows where it came from Stock is tracked as lots, each with its received date, supplier and the price that was paid. When a plan needs 120 kg of pork, the system can fill it from three different deliveries, oldest first, and the cost of the plan comes from what those specific lots cost. Whatever the lots can't cover becomes a shortage, and the shortages become the purchase list: what to buy, how much and from which supplier. If a plan is short on anything, the system refuses to run it and tells you exactly what's missing, and once a plan does run, every lot it used is recorded against it. ## Keeping the numbers honest The biggest weakness of a spreadsheet is that anyone can overwrite a cell. Here every delivery, production run and stocktake correction goes into a ledger as a movement, closed months can't be edited, and a mistake gets a correction entry instead of a silent rewrite, along with a record of who changed what and when. Components have minimum stock levels that show up on the dashboard when they run low, and production, ingredient use and stock can all be exported to CSV. ## Testing it on their own data I seeded the test deployment with the customer's own workbook, 8 products and 33 components, and ran it on FastAPI with server-rendered pages, Postgres on Neon and Vercel. It came together over 27 commits between 5 April and 18 May 2026, with 44 automated tests running on every push to main. My favourite bug from that stretch: the first production deploy served every page without its stylesheet, so the login screen showed up as plain text. A static route and two regression tests later, it was fixed. ## The part we didn't get to deliver The next step was purchase forecasting, suggesting what to buy before the orders that need it even arrive, based on the yearly pattern in orders, how each supplier delivers and how each buyer tends to order. It was still in development when the project wrapped up, so it was never delivered or run in production. The plan was deliberately conservative: start with a simple seasonal baseline (the same period last year, or a recent average), move to gradient boosting on order history, seasonality and supplier behaviour only for the products where it beats that baseline on past data, and feed every suggestion through the same shortage engine so nothing reaches the purchase list without being checked against real lots. Nothing would be ordered until the technologist approved it. Since the system started fresh instead of importing years of workbook history, any forecaster would have begun with very little data, which is exactly why the plan started with a baseline. Looking back, the workbook's arithmetic was never the problem. What it was missing was memory: which lot, at what price, and who changed what.