Building a Traceability Tool for Our Bakery

I talked a bit about the .NET app I've been working on a while ago, but I never really shared how or why it came to be.

I made this app because our bakery decided to pursue SQF certification. One of the requirements is traceability which means we need to track every raw ingredient from receiving to production. We already had the paperwork: receiving documents for every ingredient and batch control sheets for each batch we produce. But doing anything with them was a nightmare.

Each day, I get handed these papers and manually input them into the system. Now, if I’m given a lot number to trace, I can plug it into the app and instantly get a report with everything we need, receiving dates, batch usages, and it’s all printable.

Before this app, running a mock trace meant digging through filing cabinets, cross-referencing lot numbers across different dates, and scanning through every single batch control sheet. It was slow and prone to human error.

Right now, the whole thing runs on my laptop. It's a monorepo setup, with a backend API, a Blazor frontend, and a shared library. Everything's version-controlled with Git, and I perform regular backups of the database. Still, I have a single point of failure: my laptop. If it goes down, I can re-pull the repo and import a backup, but that’s not a process I should ever have to rely on.

So I’ve decided to clean this up and follow better practices. My plan:

Create new branches for staging/production
Host the app on Azure
Whitelist the bakery's IP so only we can access it
Configure the Azure Web App to auto-deploy from the prod branch

Another big pain point, and honestly, a major oversight, is that the scanned documents are stored locally, on my laptop, with no backup. If the machine dies, those documents are gone. That’s unacceptable. So, I’ll also be setting up Azure Blob Storage to handle document uploads and retention, making them accessible directly from the app.

There’s still more to do: cleaning up some parts of the project and writing a lot more tests. I know it’s a small project for a small business, but it solves real problems. And I want to treat it like a real software project. I'm even considering containerizing it with Docker, or going full overkill and experimenting with Kubernetes, just to gain hands-on experience using these tools in a real-world context.