Retail Software Implementation: What a Two-Month ERP Rollout Taught Me

The first business system I implemented, I built at nineteen, alone, in about two months. Looking back across twenty years of implementations since, almost nothing I got right in those two months had to do with the code.

The company distributed newspapers and magazines through more than fifty kiosks across a city. Deliveries, stock, returns, a warehouse, cash handling and settlements with suppliers, all against a product with a brutally short commercial life. A newspaper loses its value faster than milk does, and every process in that business was shaped by that fact.

I was the only programmer. A systems administrator taught me how to break a problem down and keep code in some kind of order. Everything that had to do with implementation — talking to people, changing how they worked, getting the thing adopted — I learned by getting it wrong in front of an audience.

Fifty kiosks, two months, and no idea it was unreasonable

The job was to take an existing software base and extend it to cover operations, stock and cash across the whole company. What strikes me now is how the CEO handled it. From the first conversations he talked to a nineteen-year-old about business processes, how departments handed work to each other, where information got stuck and what he thought could be organised better. Not specifications. The business.

Part of why it worked is unflattering: I did not know enough to know the task was unreasonable. An experienced manager would have run a risk assessment, drafted a plan, asked for a team and explained why two months was close to impossible. They would often have been right. Not understanding the size of a problem occasionally supplies energy that a properly calibrated person would never spend.

Not knowing how unreasonable a task is can be a real source of energy. It is not a plan, and it does not survive contact with the second location.

Written at night, tested in the morning

The method, if it deserves the word, was this: write a piece at night, put it in front of real employees doing real work in the morning, watch it through the day, find the requirement I had missed, repeat. When I ran out, I slept in the server room, which was kept at eighteen degrees and is survivable at that age. I did not think of it as a pilot or a phased rollout. I called it coding at night, launching in the morning, fixing during the day.

Years later I read Hackman and Oldham's 1976 work on how job design produces motivation: autonomy, visible results, a sense that the work matters, and immediate feedback. I had all four by accident, because there was nobody else to have them. The distance between a decision and its consequence was a few hours, and the feedback was delivered by people who had to live with what I had shipped. It was rarely diplomatic and it was never wrong.

That is the strongest argument I know for keeping implementation people close to the operation. In larger companies I worked in afterwards, departments, handovers and approval layers stretched that distance to weeks, and the quality of the feedback degraded the whole way along.

Why heroics stop working at the second location

The system went live and went on to run the books for a business with more than fifty kiosks and several hundred wholesale buyers. I got a $300 bonus and spent it on a bicycle, which at nineteen was a defensible allocation of capital. Work continued after go-live: replenishment logic, purchase order generation, recommendations for writing off returns, and eventually a warehouse module that told people where to walk. A second programmer joined and I became a mentor without any idea how to be one.

Which leads to the correction I would give my nineteen-year-old self. Personal responsibility carries a first project remarkably far, and then it stops. No organisation should depend on one person's willingness to give up sleep. It has to convert into process, documentation, knowledge more than one person holds, and systems that keep running without rescue. The related point about the reporting layer specifically, that it cannot be specified once and left for years, is the subject of why your reporting stack can't be a one-time project.

The questions that tell you an implementation worked

The temptation is to judge a rollout by whether it was delivered on the plan and whether the engineering is clean. Architecture does matter, and bad architecture becomes a business problem eventually, just on a slower clock. But a technology team cannot grade itself only on how well its own process is organised. These are the questions I ask instead, a month or two after go-live:

• Did error rates actually fall, and can you see it in the data rather than in impressions?
• Do people finish the same work faster, or has the work simply moved to somebody else?
• Does management get the same information earlier, or only in a nicer format?
• Is stock more understandable than it was, by location, category and period?
• Which manual steps disappeared entirely, and which ones just changed hands?
• Did any business decision change because of the system, and can you name the decision?

If none of those can be answered, the system is live. That is not the same as implemented, and the gap between the two is where most of the money in these projects is lost.

Software becomes part of the operation, not a tool beside it

Eric Trist's work on sociotechnical systems, which is older than most of the software we argue about, makes the point better than I can. A new system does not only replace a tool. It changes relationships, who decides what, how responsibility is distributed, how much people trust what they are looking at, and what they end up arguing about.

If people do not trust the underlying data, cannot follow why the system recommends something, or spend part of every day correcting it, the damage has left the software and entered the working relationships around it. The arrival of AI has made that argument sharper, not softer. A recommendation nobody can inspect is a trust problem before it is a user experience problem.

What we carried into marql

marql is a layer above the POS, accounting and e-commerce systems a retail chain, restaurant group or franchise network already runs, read-only and hosted in the EU. It does not replace a POS or an ERP, and nothing is written back into them, which is a deliberate choice about how much of an operation one rollout should be allowed to disturb at once.

The commitment we make is narrow on purpose: a qualified stack review, a first live view within 24 hours, and pricing from EUR 200 a month. What we would rather be judged on is the list above — whether an operations lead gets an answer earlier than they used to, and whether it changes anything. One concrete example of what that looks like when a number goes wrong is in how to investigate an inventory shortage.