From paper order books to a live order system

Canberra Limited imports and distributes consumer goods across Bangladesh. When we met them, every order in the business started on paper.

A sales representative walked into a shop, wrote the order in a book, and phoned it through to head office later in the day. Someone at head office typed it into a spreadsheet. Stock figures came from a different sheet, updated by a different person, at a different time. By the time an order was confirmed, the numbers it was based on were already old.

We replaced that with three applications: one API, an admin panel for head office, and a field app for the representatives. This post is about why we split it that way rather than building one system, and what actually changed for the people using it.

The problem was not the paperwork

It is tempting to look at a paper order book and conclude that the fix is a digital order book. It is not.

The paper was a symptom. The real problem was that nobody in the business was looking at the same numbers at the same time. A representative promised stock that had been sold that morning in another district. Head office approved orders it could not fulfil. Management could not answer a simple question — what is selling, where — without asking three people and waiting a day.

So we did not start with the form. We started with the question of where the truth lives.

One API, two front-ends

The answer was a single Laravel API that owns orders, products and customers. Nothing else writes that data. Both front-ends ask the API and both get the same answer.

On top of it we built two applications, because two very different people were going to use them.

Head office got a Next.js admin panel. It is a desk tool: wide tables, filters, approval queues, pricing, inventory, reporting. It assumes a keyboard, a large screen and someone who will be in it for hours.

Field representatives got a separate Next.js application, installable on a phone. It is a shop-floor tool: large tap targets, a short path from customer to order, and as few screens as possible between opening the app and confirming a line item.

We could have built one responsive application and shown or hidden parts of it depending on who logged in. We have done that before on smaller systems. Here it would have been the wrong call.

What the field app had to survive

A representative uses this application standing up, in a shop, holding a phone in one hand, while the shopkeeper waits. That is the design constraint, and it is unlike anything head office does.

It shaped the decisions:

• The order screen leads with the customer and the product search, because that is the first thing that happens in a real conversation.
• Stock is shown against the line the representative is adding, not on a separate inventory page they would have to go and check.
• The app is installable, so it opens from the home screen like any other app and does not lose its place behind a browser tab.
• Nothing important sits behind a hover state, because there is no cursor.

If this had been one application with a mobile breakpoint, every one of those decisions would have been a compromise with the admin panel's needs. Instead the two are free to be good at different jobs.

What head office got

The admin panel is where an order becomes real. Orders arrive from the field, land in a queue, and are approved and dispatched from there. Retailers and routes are managed in the same place, so who covers which shops is a fact in the system rather than something a manager keeps in their head.

Reporting sits on the same data. Because every order is written through the API and never re-keyed, sales by product, by area and by representative are simply queries. There is no reconciliation step, because there is nothing to reconcile — there was only ever one copy.

We rebuilt the corporate website alongside the system. It is a separate concern and a separate application, and it is the only one of the three that the public ever sees.

Why we did not build one application

The argument for one application is real: less code, one deployment, one login, one place to change something. On a small system we would take it.

We split this one for three reasons.

The users have opposite needs. Optimising a screen for a phone in a shop makes it worse for a desk in an office, and the reverse. One codebase would have meant permanently arbitrating between them.

The release risk is different. The field app changes when the sales process changes. The admin panel changes when the back office changes. Keeping them apart means a change to one cannot take the other down in the middle of a working day.

The API outlives both. The front-ends will be redesigned. Some day one of them will be replaced entirely. The data model, the order lifecycle and the business rules should not have to be rewritten when that happens, so they do not live in either front-end.

That third reason is the one that matters most over time, and it is the one that is hardest to argue for on day one, because it does not make the first release faster. It makes the fifth year cheaper.

What changed

We do not publish figures we cannot stand behind, so here is the qualitative version, which is what the client actually talks about.

An order now exists the moment it is taken, in the shop, with the retailer standing there. It is not re-typed. Nobody phones it in. The representative is not carrying a book of orders that only becomes real at the end of the day.

Head office sees orders arrive instead of collecting them. The work shifted from data entry to decisions — approve, hold, dispatch — which is what those people should have been doing all along.

And management can ask questions of the system directly. That is the change that is easy to underestimate. It is not that reporting got faster; it is that reporting became possible without interrupting three people.

What we would tell another distributor

If you are running a field sales operation on paper, the value is not in digitising the form. It is in deciding, once, where the truth about an order lives, and then making sure every screen in the business reads from that one place.

Once that is settled, the rest is a design problem: give the person in the shop a tool built for a shop, and the person at the desk a tool built for a desk. They can be two applications. They should not be two versions of the truth.

We build systems like this for distributors, importers and anyone whose orders currently start life on paper. If that sounds like your business, we are happy to look at it with you.