Every food supplier we talked to had the same spreadsheet. It worked at three accounts. It broke around eight. By twelve, it was held together by one person who couldn't take a day off.
The Spreadsheet That Finally Broke
We kept seeing the same story in food logistics. A small producer lands their first supermarket account, then a second, then a third. At that stage, a spreadsheet is fine. It is not elegant, but it works.
Around eight accounts, it stops being a tool and starts becoming a liability. The file is still "working" in the technical sense, but now it has 11 tabs, notes from three different people, driver columns that no longer match the actual routes, and a returns sheet nobody wants to touch because the formulas look dangerous.
The person running it stops being a coordinator and becomes a single point of failure. They cannot take a real holiday. They cannot get sick without the whole week getting messier. Deliveries still go out. They just go out with more confusion, more calls, and more avoidable mistakes.
That pattern showed up often enough that it stopped looking like bad luck.
The break was not really about the file
It is easy to tell this story as "the spreadsheet got too big." That is only half true.
What actually broke was the operating model around it.
The spreadsheet was being asked to behave like a delivery system, a returns log, a document archive, a route planner, a branch directory, and an account history all at once. It was carrying more operational responsibility than a spreadsheet should ever have to carry.
So the real break point was not file size. It was when too much of the business started depending on work that happened outside the file:
- phone calls to confirm what the driver really delivered
- message threads to clarify branch instructions
- inbox searches to find the right credit note
- one person remembering which account had special receiving rules
Once that happens, the spreadsheet is no longer your system. It is just the place where fragments of the system get written down.
The actual problem
The businesses we spoke to were not bad at logistics. They were stuck between two categories of software that both missed the point.
On one side: spreadsheets, which are flexible and cheap until they quietly become fragile. On the other: ERP systems, which expect long implementations, internal IT support, and an organization much larger than the one actually using them.
ERP software makes sense for a 500-person distribution company. It does not make sense for a 12-person food producer with eight supermarket accounts and three drivers.
Between "spreadsheet" and "ERP," there was basically nothing. That was the gap these businesses were living in every day.
What the hidden tax looked like
The tax rarely appeared as one dramatic failure. It showed up as friction.
A return got logged at the end of the day instead of at pickup.
A buyer asked for a credit note update and somebody had to reconstruct the whole sequence from paper and memory.
Two people edited the same operational record in different places.
Drivers kept repeating the same delivery exceptions because the exception never became part of a shared system.
Each of those moments costs a few minutes. Across a month, they cost attention. Across a year, they cost margin, credibility, and sometimes accounts.
The thing that struck us most was how often these were good businesses being held back by bad operating scaffolding. They had already done the hard part of making and selling a product supermarkets wanted. What they lacked was software that respected the reality of their size and their workflow.
What we set out to build
We set out to build something that could replace the spreadsheet completely without demanding a full-time logistics manager to operate it.
The core loop is simple: schedule the delivery, record what went out, process what came back, generate the paperwork, close the job properly. Every supplier delivering into supermarkets runs that loop, whether they do it once a day or ten times a day. If that loop takes 30 minutes instead of three hours, the same person can run a much larger operation without everything living in their head.
That sounds modest. It is not. In operational software, "modest" is often what actually changes the business.
We launched in June 2024. Since then the platform has expanded in the directions customers kept pushing it:
- stronger reporting and dashboard visibility
- PWA access for drivers and warehouse teams
- PDF output that works in the field
- multi-language support for mixed teams
- B2B coordination tools for businesses sharing delivery networks
But the center of gravity has stayed the same. We are still solving for the supplier that has outgrown spreadsheets and does not want to buy an enterprise suite just to run a disciplined delivery operation.
What good software should do here
Good logistics software for this tier of business should not try to impress people with conceptual breadth. It should reduce coordination load.
It should make branch-level detail easy to keep current.
It should make returns less ambiguous.
It should make a delivery note, a return event, and a credit note feel like parts of the same record rather than three unrelated chores.
And it should let a growing team share the same operational truth without needing a daily verbal handoff to stay aligned.
That is a much more useful ambition than "digitally transforming the supply chain," which is the kind of sentence software companies write when they are trying not to say what the product actually does.
Where it does not fit
If you are delivering to three accounts and the spreadsheet still feels calm, predictable, and easy to manage, you probably do not need this yet.
If you are at eight or more accounts, juggling multiple drivers, and dealing with returns every week, the coordination overhead is already real. It keeps growing every time you add another location. That is usually the point where the spreadsheet finally gives up and a proper system starts earning its place.
What the vision actually is
The vision is not abstract.
It is a supplier team being able to answer operational questions immediately.
It is a buyer not having to chase for credit notes.
It is a driver not carrying half the business process in their own memory.
It is a growing company adding accounts without feeling like each new branch is another spreadsheet tab waiting to become a problem.
That is what wallmarkets is for. Not replacing every other business system. Not pretending logistics is glamorous. Just making a supplier operation coherent enough to scale without becoming fragile.
The first-week setup guide is the practical version of that vision. The company positioning post explains the boundaries more directly.