Why I built BakeryMS

When we opened Bazaar Bakery in Riga, I did what every bakery owner does when they hit a problem: I went looking for software that already solved it. What I found convinced me to build my own — not because I wanted to, but because nothing on the market actually fit how a bakery works day to day.

This is the story of why.

The software that existed didn’t fit

The options split into two camps, and neither worked for us.

On one end were the big international platforms like Cybake — powerful, but expensive, and so dense that I genuinely couldn’t tell what was inside the package before committing. On the other end were the local production systems like Moneo, built to support factory output but built around the office, not the people actually making the bread.

That distinction turned out to be everything. Almost every system I looked at assumed you had someone whose entire job was sitting at a desk, typing in what got produced. Moneo, for example, doesn’t do label printing, and its source of truth is whatever the office worker enters into the production log. So you need one person doing data entry, all day, every day. My question was simple: why would I do that when I have a team on the floor I already trust?

That question became the whole design philosophy of what came next.

Problem one: nobody knew the best-before dates

The first real pain wasn’t glamorous. It was best-before dates.

We produce doughs, fillings, components — things that need a shelf life written on them. But an employee mid-shift doesn’t have time to hand-write a small sticker with some best-before date they’re guessing at. There was no consistent system telling them what the shelf life actually was. Every label was improvised.

So I built the crudest possible fix: an Excel spreadsheet linked to a Zebra printer. Select a product, and it printed a proper sticker — best-before date, the data we needed — and stored everything in Google Sheets. It worked. For a while.

Then we opened a second location, and the data volume alone brought the whole thing to its knees. Google Sheets got slow, fast. It was clear I needed a real, modern approach — something built for 2026, not a spreadsheet holding on by its fingernails.

Problem two: you couldn’t see what your team actually produced

The second pain was bigger and harder to ignore. With the tools we had, I could never actually tell how much an employee produced, what they produced, or when they produced it. That data simply didn’t exist in any usable form.

For a business where production is the business, that’s a hole you can’t run blind through forever. That was the point where a spreadsheet stopped being enough and the real app began. From there it grew — feature by feature — into what a bakery genuinely needs.

The one rule: respect the employee’s time, and trust their data

Everything in BakeryMS is built on a principle that most software gets backwards.

We never let the app get complicated, because we’re always asking the same question: how much time does the employee have to log this? The answer is: almost none. So the app has to be fast, or it doesn’t get used — and software that doesn’t get used is worthless no matter how clever it is.

Trust on the floor, verification in the background. You get accurate data and you free up the people making it.

And here’s the part that makes us different: we trust the employee’s data. Instead of routing everything through an office gatekeeper, the system is structured so carefully that it’s genuinely hard for an employee to make a mistake. Every action is logged, and every move is checked by the office.

Everything starts at the label

The whole system begins with one action.

A factory worker produces something, goes to a laptop, enters the amount, and gets stickers to label the finished product. Each label carries the best-before date, the quantity, a barcode unique to the factory, the product name, and any notes.

That label is the single source of truth for everything downstream. This is the feature no other system could offer us — and the reason others can’t is exactly why they need a full-time data-entry person. We put the source of truth in the hands of the person who made the product, at the moment they made it.

Killing the WhatsApp order chaos

The next thing that pushed me to build was multi-location, and the state of the art genuinely surprised me.

In this day and age, there was no proper way for shops to use a tablet to send orders, check data, and analyze it. Everything had to be custom-built — and custom coding, for us, would have cost a fortune. So most bakeries end up where we were: orders flying around in messy WhatsApp threads.

BakeryMS is multi-location and connected directly to the factory. Shop orders arrive instantly. We can see them the moment they land and plan the next day’s production faster than ever. No more scrolling back through chat to figure out who ordered what.

Recipes that actually manage themselves

Then came recipes — and this is the part I’m proudest of.

Before, we used messy, hard-to-follow Excel sheets: manual formulas, manual linking, prices that had to be updated by hand, and no real home for a recipe to live. I have two financial specialists on my team who checked every formula so the cost-of-goods and margin calculations are exactly right. Then we built the intelligence on top:

• AI invoice parsing updates prices automatically. It tracks price changes and flags stale items. Forget to swap a frozen-berry supplier for a cheaper one, and the system notices: this ingredient hasn’t been updated in 30 days — recheck the recipe.
• Automatic EU-compliant nutrition and ingredient lists. Each recipe has a built-in nutrition generator that pulls the full recipe and produces an accurate nutrition calculation and a regulation-based ingredient list — so you’re not spending hours second-guessing your labeling.
• Every recipe is linked to what the factory produces, which gives us a precise ingredient-consumption plan, day to day and month to month — a real production pattern, not a guess.
• Step-by-step technical production documents, generated for sanitary inspection, so your team follows best practice for how each recipe should be prepared.

There’s more to the recipe engine than fits here — I’ll go deeper in a separate post.

Deliveries designed for the delivery guy, not the office

Most systems that handle deliveries build the interface for the office. We did the opposite.

We spent years crafting the fulfilment page around the actual delivery driver, based on advice from the person who literally does our deliveries. He comes first, the office second. He knows what’s packed and what’s missing. If he can see something’s been underproduced, he can edit the order on the spot. We track all of it, and it becomes a fulfilment report. The person closest to the problem gets the tool built for them.

Monthly inventory without expensive hardware

One of the last big pieces was monthly inventory — and in other systems this is where the costs get brutal, often requiring specialized, expensive counting devices.

We built it so every employee gets a unique monthly link and counts on their own smartphone. No special hardware. It’s included in the app for the one price. Results sync live the moment they count, with backup so nothing gets lost. Simple, cheap, and genuinely useful.

Why this is different: it’s built on real experience

The thread running through all of it is that nothing here is theoretical.

We run Bazaar Bakery — seven shops and one central factory. That’s an enormous amount of real, daily human input flowing back into the product. We built BakeryMS on the latest AI and coding advances, but the reason it works isn’t the technology — it’s that every feature exists because we hit the problem ourselves, on the floor, at closing time, and needed it solved.

And it keeps growing. What’s coming next:

• iOS support (we’re currently Android-first), paired with a customer loyalty feature.
• Multiple shop templates — right now there’s one web template; soon there’ll be three, so bakeries have everything in one place.
• Fully synced products across the whole system, so you never do the same work twice across different platforms.

That’s the story. BakeryMS exists because I needed it and couldn’t buy it. If you run a bakery and any of this sounds like your Tuesday, it was built for you.