Food Cost & Profit Tracker

My girlfriend was selling food through delivery platforms, and the orders made it look as though things were going well. Ingredients were being bought, meals were going out and the platforms were taking their share. What she couldn't easily see was how much money was left after all of that.

I built Food Cost & Profit Tracker to make those costs visible. It's a private app that connects ingredient purchases, recipes, stock and manually entered sales, so she can understand the estimated margin on a dish and compare the channels selling it.

A sales total leaves out quite a lot: ingredients, platform commission, spoiled food and the other expenses involved in running the operation. I wanted to connect each sale to those costs so the reports could explain what was left.

I made ingredient purchases the starting point. You record what you bought, the quantity and the price, then connect those ingredients to recipes. Recipes support quantities per portion and batch yields. The batch option matters because cooking a pot of something and dividing it into portions is a more natural starting point than treating every serving as a separate cooking exercise.

Each sales channel can have its own selling prices and commission rates. The recipe stays the same, but the estimated margin changes depending on where the customer ordered. That makes it possible to compare direct sales with delivery platforms without maintaining a separate recipe for each channel.

Orders are entered manually in the app, with the sales channel selected for each one. Recording a sale calculates its estimated margin and deducts the ingredients from stock. That connects the sales record to the food used to fulfil it, instead of leaving stock and sales as two unrelated lists.

For stock costing, I used purchase batches with the oldest available stock consumed first. If the next batch of chicken costs more, that price affects orders using the new batch. It doesn't change the ingredient cost of an order that was already made from earlier stock. Keeping that distinction makes changes in purchase prices easier to follow.

The reports include recorded operating expenses and spoiled ingredients. Both can disappear from view if you're only looking at revenue and recipe costs. Missing recipes or purchase costs also produce warnings, so gaps in the inputs stay visible when someone is reading the results.

I describe the margins as estimates because they depend on what has been recorded. The app gives the seller a clearer basis for decisions, but an incomplete purchase history or a missing expense still matters. Showing those gaps is part of making the figures useful.

The daily overview brings attention to things that need action. Low-stock alerts, buying lists and comparisons across products and sales channels help connect the reporting to the next purchase or pricing decision.

I built the interface around phone use, with Thai and English interfaces and installation as a PWA. The backend uses Go and SQLite; the frontend uses React, TypeScript and Mantine.

I also explored a SaaS version, adding separate shop accounts, user access, plans and an admin panel. That work remains a private shop experiment with support for controlled, invitation-only testing.

The most useful outcome was a pricing decision. One delivery channel was keeping my girlfriend busy while losing her money. Once she could see the costs, she started adjusting prices.

That was the reason for building it: making the relationship between orders, costs and money left over clear enough to act on. The practical result is that she can see where the money is going and make better-informed pricing decisions.

Read the project overview on NikoCodes.