Order Management Automation Across a Retail Partner Network

Our partner runs a nationwide partner network in retail: points of sale that order stock on a recurring basis and settle with a central office. We built the system that handles those orders, the work of field sales reps, and the shipment logistics behind both. It is not an off-the-shelf order management product and it was not a one-off delivery. It is software written for one business and kept alive on a maintenance retainer since the start of 2026.

The problem it started from sounds the same in every growing retail business. People retype data between systems and start making mistakes when volume spikes. The difference here is that there is no single warehouse on the other side, only points scattered across the country.

It started as training, not a build

The first months did not look like a software project. We ran training sessions and working consultations on our partner's own cases. Not textbook examples. Their orders, their paperwork, their complaints.

Over time the scope grew, and training turned into building a system, because the trust we built on the smaller things carried over into agreement on something bigger.

What the system does day to day

Three things drift out of alignment fastest in a distributed partner network, and the system exists to hold all three in place.

Orders. An order placed in the panel and an order sent by SMS enter the system through the same path. Placing one requires no account and nothing to install.

Field sales work. A rep registers a new point on site, not back at the office in the evening. Company details fill in on their own, so nobody retypes them from a notepad and nobody mistypes them.

Shipments and settlement. Every parcel carries its own state and its own settlement record. A discrepancy shows up at the moment it appears, not at month-end close.

Invoicing, SMS communication and a role-aware back-office view sit on top of that. In most companies of this size those jobs are done by several people, by hand, across spreadsheets that never quite agree.

Why we rewrote the panel from prebuilt blocks into code

The panel started in a tool where screens are assembled from prebuilt blocks instead of written from scratch. That was the right call at the beginning. The first modules shipped faster and cheaper than hand-written ones would have.

Then the panel grew. At a dozen-plus modules and several hundred UI elements, problems appear that are invisible at three screens. Keeping test and production in step cost more every month. Answering "what changed between these two versions" was guesswork. A change in one place could disturb something nobody had opened in months, and there was no test to catch it.

We proposed the move to plain code instead of blocks. Our partner did not ask for it. The reasoning was operational, not aesthetic.

• Version history. The panel lives in a code repository, so every change has an author, a timestamp and a way back.
• Separate environments. A change is seen on test first, then by the people who work in it every day.
• Automated tests on critical paths. The flows whose failure stops orders are checked on every change.
• Logs and error tracking. When something breaks we know what and where, instead of asking a user for a screenshot.
• No ceiling. Code can do the thing the block library never anticipated. At this size, that comes up regularly.

The old panel kept working until the new one took over its job, with no downtime for our partner to worry about. The migration itself cost several weeks that added no new features for our partner, and we said so before we started. They took us at our word, because up to that point we had always delivered what we promised. The return arrives on every fix afterwards, because the distance from report to deployment got shorter, not because writing the change got faster.

How it is built

The technical layer in three points, because the question comes up anyway, without getting into what our partner would rather keep to themselves.

• Automations running in the background. Integrations and processes that work without a screen anyone looks at. More than 10 run in production.
• An operational panel written from scratch. A dozen-plus modules mapped to office and field roles, not assembled from prebuilt blocks.
• A simple database. No rigid schema, so adding a field never needs a migration.

Everything runs on our partner's own infrastructure, so adding a user does not add a licence fee.

How the engagement works

A maintenance retainer, not a project with a handover and a goodbye. We agree on hours per month, and inside those hours sit fixes, new modules and whatever the month turns up.

In practice it means we know this business from the inside, so our partner does not re-explain context every time. A change gets raised in a conversation, not in a ticket form. Some of it we raise ourselves, because we see it in the data before the person working inside a single module does. Our partner does not have to watch whether something is working, because that is our job, not theirs.

After more than a year and a half of working together, we talk like a team that knows its own weak spots and strengths, not like a vendor and a client. That shows up most clearly in the fact that new ideas for the system now come from both sides, roughly equally.

What it costs depends on hours and on the SLA tier. Our retainers start at 3,875 PLN net per month, and that is an entry point rather than an average. What our partner pays is their business, not ours, so we are not publishing it. The calculator prices a range for your own scope.

What this case does not prove

We are not publishing our partner's name, the specifics of what they sell, which tools this runs on, how many points the network has, or how many orders pass through the system each month. Our partner asked for that privacy, and this is a relationship built on trust, so we respect it the way we would respect yours.

We are also not claiming that moving from prebuilt blocks to code is always right. On a three-screen panel it would be money spent for nothing, and we would say so.

And if you are shopping for the cheapest supplier, we are not it. This project is still running because someone pays for someone else to keep watch over it, not because they have to.

If your own people are retyping data between systems and making mistakes when volume spikes, that is the same problem in a different industry. We usually start with one process, the one eating the most hours, so the effect shows inside two weeks.