Why a store full of procedures still failed an audit

What a normal shift is holding

Take a normal 7am opening. The manager is dealing with fire doors, cash routines, red orders, stock work, weekly checks and the team brief. Customers start arriving. Orders need picking. Returns appear. Trade+ has its own list. Front of house needs filling. The warehouse keeps producing more work, and a delivery may be due later.

Each job makes sense on its own. Holding all of them together is where it gets messy. A customer is standing at the counter, so the customer wins your attention. A safe count can sit quietly. So can an email. Training will wait until its deadline is close enough to become a problem. This is how important work goes missing in a busy store — it rarely disappears with any drama. Something louder simply takes its place.

I know because I do it too. I can forget something, get dragged into an escalation, or focus on the obvious problem in front of me. Personal accountability still matters. A decent system makes the right action easier to see and the unfinished action harder to lose.

The handover was another weak point. Jobs could build through the morning, then land on the late manager with very little context. By close, it looked like their backlog — but the actual ownership had been vague all day. The audit showed what happens when that pattern reaches compliance and stock accuracy.

Five answers every job should give

I wanted every important job to answer five things when someone looked at it. What needs doing? When does it belong in the shift? Who owns it or completed it? How should it be done? What state is it in now?

Managers were reconstructing those answers from fragments, and that takes more thought than it should — especially when the store is busy. My design question became simple: how do I take the week out of managers' heads and put it somewhere the whole shift can see?

Five hours to version one — then the store took over

I released the first version on 2 August 2026 after roughly five hours of AI-assisted development. It had a weekly calendar, timed routine blocks, checklists, notes and local progress — enough to test the main idea: "running the store" could be broken into a repeating weekly script and the work that changed each day. The script could appear automatically. Managers could use their judgement on the exceptions.

Testing began on 3 August. The first version was wrong in useful ways.

3 August — the store corrects the plan

Morning Paperwork needed more time. The Manual Trading Check belonged on Monday. Payroll sign-off had a hard deadline. Two task lists were making the shift harder to read, so I merged them. Sunday had the sales tracker twice, so one went. These were small changes in the code and big changes in use. A planner can look tidy and still tell the store to do the wrong thing — timing, wording and repetition are part of the product.

4 August — collecting evidence

Deliveries exposed the next problem. A tick could say the work was finished, but it couldn't tell me how many invoices arrived, how long the job took, or which products were missing. It also couldn't tell the difference between a genuine finish and someone hitting Stop by mistake. I rebuilt the delivery workflow as a data card: delivery number, invoice count, missing SKUs, processing time, with the timer asking for approval before saving so a bad tap can be corrected. I added a weekly stock count, front-of-house contingencies and colleague initials on ticks and timers. Supabase gave work devices one shared state; home devices became practice-only — they can pull the real plan for testing without pushing random taps back into the store.

5 August — giving work the right memory

Daily checks should clear tomorrow. Training should stay done. That sounds obvious, but the first data model treated too much work the same way. A GDPR module may run for weeks — it has a deadline, its own group of colleagues and a completion state that needs to survive overnight. So Training became a separate, persistent workflow: each module active or dormant, carrying its own people list, every completion recording the date and the person who ticked it.

I also started deleting things. The weekly gold-silver-bronze focus control competed with the calendar, so I removed it. A free-text notes box was taking space from the checklist, so that went too. Duplicate controls disappeared. The app improved once I stopped assuming every idea deserved to stay.

6 August — designing for the next manager

The early planner focused on the person running the current shift; the next manager still had to piece the day together. I rebuilt Handover as a shared action list that survives the date changing — a job stays open until someone completes it, with deadlines, Important and Urgent flags, and completion stamped with date and initials. The handover screen also shows the shift at a glance: checklist completion, delivery progress, training left to do. The next manager can see the shape of the day without opening every block.

Stock Monster came next: managers enter the delivery stock remaining several times a day, and the planner calculates the clearing rate, whether the pace is rising or falling, and the rate the team needs to hit to clear by 19:00.

By the end of that day, the log held 21 build jobs and 91 individual changes. The useful part is the trail — I can see where the original idea met the store, failed and got corrected.

A calendar on the surface, operational memory underneath

Clinch looks like a calendar. Its real job is operational memory. Retail work has different lifetimes: some jobs repeat tomorrow, some collect over several days, some pass between managers, some need a deadline, a timer or a number — others only need to appear at the right moment with a clear instruction. Daily checklist data resets by date. Training stays with the module and colleague. Handover and audit actions stay open until they're resolved. The stock count carries across the week.

Once I saw that, the product made more sense. The design problem was choosing the right kind of memory for each job.

The feedback form asks for the Problem, Root Cause and Solution — I wanted feedback to explain the failure before asking for another button. Ticks, timers and completed actions carry colleague initials. Work devices share live data through Supabase; practice devices can explore the current plan without writing back to it.

That's where the name landed, too. To clinch a nail is to bend the point over on the far side so it can never work its way back out — the difference between a fixing and a fixing that holds. The audit didn't fail because nobody did the work; the work worked loose. Nothing here is done until it's clinched.

Where the product stops — and what I still need to prove

Some things remain deliberately unbuilt: rota import and named shift assignment, the email sign-off between the early and late duty managers, the full monthly compliance schedule, and the incentive pane's sales calculations. I'm keeping those boundaries clear because a roadmap can make a case study sound better than the product actually is.

The bigger honesty: the app works in a browser, and that proves I can build it. The operational result needs store evidence — managers opening the planner during real shifts and returning to it, daily checks completed more consistently, training reaching zero before the deadline, handover jobs carrying enough context to be resolved by the next manager. I haven't completed the baseline and comparison period yet. AI made the first build fast; people still need time to form a habit, ignore it, misuse it or show me where it breaks. That part cannot be skipped.

What the store taught the product

• The pattern under the findings. The audit findings were specific; the cause underneath them was operational memory spread across too many places.
• Task data is part of the design. A clean interface cannot rescue the wrong timing, vague wording or duplicate work.
• Different jobs need different behaviour. A daily fire-door check, a month-long training module, an audit action and a delivery count each need their own reset rule.
• Delete your own ideas. The focus control felt useful when I built it. In the store, it stole attention from the schedule. Removing it made the product better.
• Writing the code was the quick part. Deciding whether a job needed a schedule, checklist, persistent action, training record, timer, count or nothing at all took the judgement.

The test that matters

Clinch began with six audit findings. It now gives me a way to test a bigger question: can a small retail team handle a complex workload more reliably when the work is visible, timed, carried forward where needed and owned — without turning the store into a surveillance exercise?

The product is ready for that test. The result still has to come from the store. My next milestone is evidence: managers using it, handovers keeping their context, important jobs getting missed less often, and the store becoming easier to run.