A store manager at a Nordic fashion chain ran a Saturday shift and then asked one of our founders a simple question: "Who designed this thing? Did they ever actually work retail?"
The question cuts deeper than small talk. Most retail software gets built in offices that have never run peak. A vendor decides what you need, ships it, and learns whether it was right after you sign. You adapt to their vision, or the system fights you.
Karo started in the opposite place. Before the first line of code. Before any wireframe. We sat on the floor with operators like that manager. In their stockroom. At their till. On their Saturday. We watched where the work broke, where they had to override the system, where they had given up trying. Then we built from what we heard, not from what we guessed.
The difference between imposed and co-designed
When a software company builds alone, a manager gets a system designed for someone else's store. Maybe it works for the big box chain with 500 employees. Maybe it works for the boutique with 3. It rarely works for yours.
The vendor decides: This is how you take inventory. This is how you schedule shifts. This is how you price. You adapt, or you override, or you give up trying.
Co-designed systems are different. The closest person to the work shapes what gets built. A manager tells us: "On Saturday, I need to see stock and staffing together, because that is where my decisions happen." We build that. Not later. Now. Not as an add-on. As the core.
This changes everything. Instead of the product imposing a workflow, the workflow shapes the product. The system fits your operation instead of the opposite.
What co-design looks like in practice
One shift manager in a Scandinavian fashion chain kept overriding the system's suggested labor schedule. Every week, the math looked right on paper. Every Saturday, it fell apart. When we asked why, she described the rhythm of her store: customer flow peaks at different times depending on the day and weather. Temperature drops, footfall rises. She knew this. The system did not.
Today, that insight is the foundation of how Karo POS handles scheduling. The AI learns from floor patterns, not just historical averages. The manager gets a suggestion that fits Saturday the way it actually happens.
That happened because she was in the design review. Not as a user test after we shipped. Not as feedback on a survey. But as a voice shaping what gets built from the start. Dozens of features came the same way. The shift where a stockroom manager asked: "Why do I have to wait for backoffice to price a markdown?" So we built pricing that works at the till. The moment a cashier said: "What if you told me which item will sell out today?" So we built that into Vera, our retail copilot.
Features die early too when operators are in the room. We have killed a dozen ideas in the first conversation because someone on the floor said it would not work on a Saturday. That alone saves months.
Why floor voices matter in product decisions
Most retail software is built by people who have never been the person who has to live with the consequences. They optimize for what they can measure in a spreadsheet. Transactions per second. Uptime percentage. Cost per license.
The people on your floor optimize for what they can see with their eyes and feel in their shoulders. Where inventory shrink happens. When customer experience breaks. How a system change ripples through the busiest hour.
The closest person to the work sees problems others miss. A backoffice team might not know that a price update at 10 AM breaks the entire merchandising workflow. A buyer's spreadsheet sits in someone's desk. A manager knows the moment it hits the floor and how it breaks the day. The AI native retail companies are the ones with floor staff in product decisions from the start.
When that happens, the language is right. Retail has its own vocabulary and its own rhythms, and most software speaks the wrong dialect. The label names make sense. The sequence of actions maps to how you actually work. The speed of the system matches the speed you need on Saturday.
More than that: the right features arrive faster. A manager in the design review can describe the moment they need help. The engineer takes the note. The build starts that week. The line between request and shipped is short by design. The system does not need documentation because it was shaped by the people who would have to read it.
Built with retail, not for it
Co-design at this depth only works when the company is organized to move fast. A software company with three layers of management between the support inbox and the engineer cannot ship a fix on the same Saturday it was reported. A company where every person who builds the product also talks to the operators who use it moves differently.
The structure is the product. When a manager calls with a Saturday problem, there is no roadmap meeting or quarterly review cycle to pass through. The feedback reaches the engineer the same day. The fix ships the next week if it is quick, the week after if it is bigger. That is not a tagline. It is a direct result of how Karo is built.
When the retailer who will use the tool is in the design review, the product comes out different.
This is what Pillar 1 means: built WITH retail, not FOR retail. Not imposed from above. Shaped by the people who run it every day. You can see the difference every shift when the system fits your operation instead of fighting it.
For a deeper look at what this means for your specific operation, read the POS migration playbook. It is the field guide built the same way Karo is built: on the floor, with operators who know what works and what does not. You can also explore how this shows up in practice with Vera, our retail copilot and Karo Backoffice.