Nobody asks where an order stands any more. The screen already says. The directors can watch the shop without interrupting it. And if my software vanished tomorrow, the shop would still sell.
Context
Mister & Miss Exclusive is a Curaçao clothing and embroidery shop. Garments, uniforms, printing, custom work. The custom side ran on an old Windows program, on fields inside the till system whose meaning nobody had written down, on spoken handovers, and on people carrying things around the building.
The problem
How do you make the next step obvious to each person, without putting the system the shop sells through at risk? Everything else follows from that one question.
The constraints, which are really the design
A till system installed long before I arrived, still running the business, with no documentation for what half its fields meant. Staff who do not use a computer as part of their day. A process that was mostly manual and partly offline: work that happens on a table, with a garment, in someone's hands. Requirements nobody could say out loud. And half a dozen roles that each wanted something different from the same job.
Key decisions
Read only from the till system, with no exceptions. The order workflow lives in its own database, so the software can change without ever touching something the shop depends on. Separate readers keep the copy in step: read the document, check it is there, check the copy is current. They sit outside the request path, so their system never picks up my traffic. Every change is logged by default, because in a shop where work passes between hands, who changed this and when is the question people actually ask. And each role gets its own screen instead of one screen behind permissions.
The boundary is enforced, not intended
An early version reached further into the till system than it needed to. I pulled it back. A limit that holds only because I remember to respect it is not a limit. The design has to make the wrong thing impossible, not just unlikely. What replaced it is duller and much better: a database login that can only read, a check that rejects anything which is not a single read, and a copy that gets verified rather than trusted.
What I got wrong
I built screens that were asked for and then never opened. More than once. Nobody was being lazy. They did not know their own requirements, which is normal, because almost nobody does. What someone asks for is a guess about the work, not a description of it. The dashboards that went unused were not badly built. They answered questions nobody had while they were actually working. What replaced them came from standing on the floor and watching. That is why I went there in person.
Letting someone non-technical ask the business a question
The same read-only limit carries a second thing. An ordinary AI assistant can be pointed at the data, so someone on the management side who does not write code can ask the business a question and get a real answer, instead of waiting for a report to be built. It is used daily: invoicing, billing questions, drafting work that used to be done by hand. Two things make it safe. It can only read, and it only reaches the parts one job actually covers. Everything else is removed, not discouraged. It also ships with the meaning of the data written down and served alongside it. An assistant left to guess what a column means will give confident, wrong answers about your own business.
The part that's genuinely hard
A computer cannot see a job that happens on a table, with a garment, in someone's hands. So every update in this system comes from a person, and every update costs somebody a tap. That one fact decides the whole design. If a tap is slow or annoying, people skip it, the data goes stale, and the dashboard starts quietly lying. Making the screens fast is not polish here. It is what keeps the data true.
What this demonstrates
Working with an old system while leaving it in charge. Requirements worked out by watching rather than written down from a meeting. Screens designed around how busy people actually behave. And the part worth checking: how much the shop depends on me is limited by the design, because the system it sells through was never mine to break.
“Before, we had to remember many details and handle several processes manually. Now, everything is properly organized in one system, our daily operations run smoothly, and we can focus more on growing the business. The software has saved us time and reduced mistakes.”
TypeScript · Next.js · React · Supabase · Read-only SQL integration · Model Context Protocol