What to look for in bakery software

Most software comparisons are done by feature list, which is the least useful way to do it. Every system has orders, products and customers on the page. The differences that matter show up three months in, on the day something changes.

So the useful test is not "does it have X" but "what does it do when Y happens". Below are the questions worth asking, roughly in the order they bite. Take them to any vendor, including this one. A good answer is specific. A vague answer is also an answer.

Does it understand a date the customer cares about?

This is the first question, and it eliminates more tools than any other.

Ordinary ecommerce is built around a dispatch date. You sell something that exists, it ships when you get to it and the date is an estimate. A cake is the opposite. It does not exist yet, it is needed on a specific day and a birthday cake that arrives the day after is not a late delivery, it is a refund.

So ask what the date on an order means to the system. Does it drive the production view, the capacity limits and the reminders? Can you close a date when you are full? Does a customer choosing a date four days away get stopped when you need seven? A system where the date is a note in a comments field will work fine right up until the week you are busy.

Can it take a deposit now and a balance later?

Custom work is usually paid in two parts. If the checkout can only take the whole amount, every deposit becomes a manual invoice and a note somewhere.

Ask three things. Can it take a partial payment and know how much is still owed. Can it hold a due date for the balance. And when that date passes unpaid, does anything happen on its own, or does it wait for you to notice? The third is where tools quietly differ. Recording a balance is easy. Chasing it is the part that gives you your evening back.

Where does a price come from?

There are two kinds of pricing here and they are not close. In the first, you type a price into a box and the system stores it. It has no opinion about whether that price is any good, because it does not know what the product costs. In the second, a product is built from ingredients and components, each carrying a cost per unit, and the cost is computed from them.

The second means the tool has to handle the awkward part: you buy flour in a 5 kg (11 lb) sack and use 40 g (about 1.4 oz) at a time, so something has to convert between the unit you buy in and the unit you bake in.

Ask to see that conversion, then ask what happens when two units cannot honestly be converted, such as a volume ingredient with no density recorded. The dangerous answer is a silent zero, because zero looks like a valid cost and is wrong on every product using that ingredient. More on the costs that go missing in pricing a custom cake.

What happens when a supplier price changes?

This is the question that separates tools built inside a working bakery from tools that were not. When you update one ingredient's price, three things could happen:

1. Nothing. Your product costs stay as they were, so your margins are fiction until you rebuild every recipe by hand.
2. Costs update everywhere that ingredient appears, at any depth, your sell prices stay put and the affected products are flagged for you to review.
3. Costs update and the tool moves your sell prices to protect the margin.

The third sounds like the most helpful and is the one to think hardest about. Ask whether it can be turned off, and what a customer sees if a price moves mid-conversation, or between a quote being sent and accepted.

Whichever it does, ask how deep the update goes. Flour is in the sponge, and the sponge is in the tiered cake, the cake pops and the trifle. A tool that updates only the recipes naming an ingredient directly has done the easy half. Repricing when ingredient costs move covers what should change, and by how much.

What happens when an ingredient's allergens change?

A supplier reformulates a sprinkle. You update the ingredient. What happens to the products you have already published, on your website and on the labels in the cabinet?

The answer worth wanting is that the tool works out the new set, tells you which products are affected and exactly what changed, then leaves the published label alone until someone confirms it. Ask it plainly: does the label change on its own, or does it wait for me?

Two more while you are there. Does the tool claim to know your jurisdiction's required list? It almost certainly does not, and one that says so plainly is more useful than one that implies otherwise. And when the same allergen arrives at two different levels, contains from one ingredient and may contain from another, which wins? The only safe answer is the stricter one.

Can you get your data out?

Ask before you put data in, not on the day you want to leave.

• Which records can you export: products, customers, orders, recipes, stock?
• In what format, and in a shape you could load elsewhere?
• Is it the full record or a summary view?
• Can you do it yourself, or is it a support request?

A tool that answers this easily is telling you how it expects to keep you.

Does it handle every channel you sell through?

Write down every way an order currently reaches you: your own website, direct messages, a phone call, a market stall, a wholesale account, a marketplace. Ask how each arrives in the system, and whether stock, capacity and your production list are shared across all of them or held per channel.

Then the harder version: what happens when you add one. If taking on wholesale means a second product catalogue with its own prices to maintain, you have not bought a channel, you have bought a synchronisation job.

What is included, and what is priced per use?

Two numbers matter and usually only one is advertised. The subscription is the first. The second is everything charged by usage: transaction fees, message sends, storage, extra users, per-location charges, anything driven by artificial intelligence and whether an integration you depend on sits behind a higher tier. Neither model is wrong, and per-use pricing is often cheaper for a small or seasonal operation. But you want to know which you are in before your busiest month rather than during it.

Who built it, and do they run a bakery?

Not a gatekeeping question, a diagnostic one. Software built by people doing the work is strangely specific in places and thin in others. Software built from a market study is evenly complete, and wrong in the same way everywhere. You can tell in ten minutes: look for the detail nobody would add unless it had gone wrong for them once, like packaging that costs differently on a collection and on a posted order.

Run the evaluation on one real order

Do not evaluate on the demo dataset. Take one real, awkward order you have already delivered, the one with three tiers, two flavours, a deposit, a date and a delivery, and build it in every tool on your shortlist. It takes an afternoon and settles arguments no feature comparison can.

Then change one ingredient's price and one ingredient's allergens, and watch what each does. Those two changes tell you more about a system's judgement than the rest of the trial put together.

ibakepro is one of the tools you could put these questions to, and it is built by two people who run a cake business, which is why its answers to those last two are what they are. But the questions are the point, not the answers. If a tool cannot give you a straight one, you have learned what you needed to know.