Rebuilding My Family's Bakery Supply System From Scratch
Why I threw out the CSV-and-local-database setup running our bakery supply business and started building one central system instead.
The way our bakery supply business runs, on paper, is simple. A central office buys raw materials in bulk, ships stock out to a handful of branches, the branches bake and decorate, and then they sell over the counter. Four moving parts.
The way it ran in software was not simple. It was barely software at all.
The old world
Each branch had an off-the-shelf POS that knew nothing about the office. The office had a spreadsheet-shaped thing I’d bolted together years ago on a local database that lived on exactly one PC. Stock moved between them the way it always has in small businesses: someone writes it down, someone else types it in later, and everyone quietly disagrees about how much flour is actually in the building.
Reconciling any of it meant exporting CSVs, emailing them around, and pasting numbers into another sheet. If the one PC with the “real” database was off, the real data was off too.
I’d been patching this for a while — a print button here, a daily report there. But every fix made the core problem louder: there was no single place that knew the truth. Every screen was reading from its own little island.
The decision
So I stopped patching and decided to rebuild it as one system with one source of truth.
The shape I wanted:
- One database, one place. All the authoritative state — inventory, purchases, deliveries, production, sales — lives in a single Postgres database on a small cloud server. Nothing important lives on a branch PC anymore.
- Everything talks to one API. No app touches the database directly. They all go through a central service that owns the rules.
- Nothing exposed to the public internet. The server sits behind a private VPN mesh, so the only things that can even reach the API are our own machines. No public login page to get brute-forced, because there’s no public anything.
I picked .NET for all of it, mostly because I already know it well and the office apps were already WinForms. The point of this project was never to learn a trendy stack — it was to make the numbers agree. Boring and reliable wins.
First cut
The first real commits are unglamorous and I love them for it. “added api/inventory.” “added a default Office for purchases.” “added auto increment ID.” Then, a few days later, the one that actually mattered:
refactored local db rw to cloud only via droplet
That’s the moment the local database died. From there on, when an app wanted to know how much of something we had, it asked the server — not a file sitting next to it. Everything since has been building on top of that one decision.
It’s not exciting to look at yet. But for the first time, if you ask two different screens the same question, they give you the same answer.
That alone justified the rewrite. The rest of this series is what got built on top.