Skip to content
All posts

Why we run our own systems first

12 August 2026operationsautomation

We don't recommend software we haven't had to fix ourselves on a bad night. Operating our own store systems is the cheapest research we do.

There is a version of this business where we read the vendor documentation, put together a deck, and tell you which platform to buy. It would be faster. It would also be guessing.

So we do it the other way around. Before we recommend a system, we run one.

Production tells you things a demo cannot

A demo runs on clean data, one user, and nobody in a hurry. Production runs on a Friday evening with three people behind the counter, one device that lost connection twenty minutes ago, and a queue that does not care about your architecture diagram.

Everything interesting happens in the gap between those two. How does the system behave when the network drops mid-transaction? What does a shift supervisor actually do when a number looks wrong: fix it, or write it on paper and move on? Which report does someone open every single morning, and which one has never been opened at all?

You cannot answer any of that from a feature list.

What operating our own platform changed

We operate an integrated store-management platform with POS integration, running in real stores today. A few things we believed at the start turned out to be wrong:

  • Reports nobody opens are worse than no reports. They create the feeling that the numbers are handled. We cut the report count and made the remaining ones arrive without being asked for.
  • The daily closing routine is the real product. Not the dashboard. If closing gets easier, the staff cooperate with the system. If it gets harder, they route around it, and every number downstream becomes fiction.
  • Integration is a reliability question, not a data question. Getting the POS to send data is a week of work. Keeping it sending data when a device is old, the connection is bad, and nobody is watching is the actual job.

What this means if you hire us

Two practical things.

First, when we say something works, it means we have watched it work somewhere it mattered, not that a vendor claimed it. When we are unsure, we will say we are unsure.

Second, we stay after launch. A system that nobody operates stops being a system within a quarter. We would rather be on the hook for it than hand you a repository and wish you luck.

That is the whole method. Run it, break it, fix it, then talk about it.