Do You Have a Working Gokart?

A guard called me about his salary. He said he was short by ₹500. For someone earning ₹17,000 a month, ₹500 is not small. It is his grocery budget for the week.

I asked HR. They said the payroll was correct, attendance verified. I asked Field Ops. They said no error, the guard had worked his assigned shifts. The customer confirmed the same. Three checks. Three confirmations. All correct.

Except the guard was still ₹500 short.

We traced it back eventually. This guard had worked an additional shift at a second location. Field Ops recorded it. We billed the second customer for that day. But the record lived in a WhatsApp message, buried in a group with 50 others. My HR person missed it. Not out of carelessness. Out of the sheer volume of information that a WhatsApp group cannot actually organise.

Nobody lied. Nobody cut corners. Every person was correct within what they could see. But the system could not hold the information it was being asked to hold. A guard had to call the founder directly to recover ₹500 he had earned.

That call did not feel like a payroll error. It felt like a question: what exactly am I running here?

WhatsApp was your entire reporting system, not just a tool for logging additional shifts. The guard's ₹500 problem happened to involve an additional shift, but the deeper failure was that WhatsApp could not organise information at scale.

I had taken over my father's business a few years earlier. I digitized a fair amount of the operations. We hit speed bumps. I fixed them. Added components. The system passed most bumps after that. I concluded it was working.

That conclusion was wrong, but it felt earned. What I did not see was the layer underneath: my team had built quiet workarounds to handle the gaps I had missed. They were competent and loyal, so the problems never reached me.

I mistook their competence for system health.

Three thinking errors were running simultaneously, and I did not catch any of them.

The first is what I now recognise as the curse of knowledge. I had digitized the business myself. I knew every component I had built. That knowledge made me confident about what the system could do. It also made me blind to what I had never built in the first place.

You cannot see a gap you have never mapped.

The second is what I now recognise as normalisation of deviance. My team encountered small failures regularly. They fixed them quietly and moved on. Over time, the fixing became routine. Nobody raised the failures as signals anymore.

The third is what I now recognise as mistaking correlation for causality. I took an action, I saw a result, and I moved on. I assumed the action caused the result. I never asked what else was running in the background to make it work. When that background stopped running, the system broke. I had no idea why. I never knew it existed.

Most AI operations content I have read skips this problem entirely. The stories are vivid: dramatic transformation, costs halved, entire workflows automated. Two further patterns make those stories feel more applicable than they are.

The first is what I recognise as the halo effect. A single impressive result colours everything that follows. One operator automates scheduling and cuts labour costs. Readers absorb the conclusion that AI fixes operations, without examining the foundation that made the fix possible.

The second is what I recognise as base rate neglect. Most of the stories I see are about operators who automated successfully. I rarely come across operators who automated the mess. Those systems run faster, with more confidence, and with less visibility. They stay off the record. I read that silence as base rate neglect at work.

For operators running operations-heavy businesses in the ₹5L to ₹50L range, the question before AI is simpler: do you have a working gokart?

A gokart is not glamorous. It is small, exposed, and slow compared to what comes next. But it does one thing that matters. It runs. It handles speed bumps. It keeps moving when you are not watching every second. It tells you when something is wrong before the whole thing breaks down.

What I had was a vehicle that moved when I pushed it and broke when I did not. My team kept pushing it. I thought it was running on its own.

Before writing a single line of code for O9X, my internal operations tool, I spent weeks mapping how the business actually ran. Not how I assumed it ran.

I mapped the workflow alone first. This forced one uncomfortable question: what do I actually know, versus what am I assuming? Then I followed one unit of reality through the entire system: one guard, from the day a field officer identifies him for deployment to the day he exits. I also tracked one representative day for each function: field operations, office work, payroll, and HR.

What I was looking for were handoff points. The places where information passes from one team to another. That is where my system broke. Not inside a team's process, but at the edge where two teams met, each holding a different version of the truth.

Only after my version was on paper did I talk to the teams, with one specific question: where am I wrong?

The HR-Ops collision surfaced in the first joint session. HR said the guard was absent. Ops said the guard was at the site. Payroll asked: do we pay him or not? Each team was correct within its own records. Together, they produced a collision that someone on my team resolved manually, every single time it occurred. I did not know this collision existed. My team had built quiet workarounds to handle it.

One involved overtime calculations that worked operationally but would not survive a labour audit. Nobody was careless. They were compensating for components the system was missing.

This is what mapping does that no report can. It finds the components you assumed were there. It surfaces the solutions your team invented to survive the gaps you did not know existed. And because the team is involved in finding the problems, they are more willing to accept the system that fixes them.

The mapping produced a project brief, a document that defined what had to be true for the system to be valid, what was not needed in the first phase, and where the hard boundaries sat. I have written about how I used that brief as a constraint weapon rather than a planning ritual. That detail is in Build Log 8.

Here is why this matters for AI specifically: in my operations-heavy business, software locks in whatever process I hand it. If HR, Ops, and Payroll hold three different truths, building AI on top does not solve the problem. You automate it. The mess runs faster, with more confidence, and with far less visibility. The mapping has to come before the build.

A gokart in a garage is not racing. It needs a road. The road is adoption.

But laying it wrong kills the system before it starts.

I did not switch everything at once. In the first week, I asked the team to move one activity from WhatsApp to O9X: site visit documentation. One action. Nothing else changed. Once that held, we moved attendance logging. The next step is payroll, the work my office team handles, and I will work through the process gaps with them directly before we migrate. One activity at a time. Each move closes one WhatsApp thread and opens one O9X record.

Migrations meet resistance. The team knows the old system. The new one slows them down at first. Change everything at once and the resistance is invisible until it is too late: two weeks of adoption, and by the third they revert. Asking them to change one thing gives you a real test. It also gives you the failures you need before the stakes get larger.

And here is what daily driving reveals that the build never does: new failures.

O9X has been live for ten days. In those ten days, my team has surfaced more than 50 small fixes. They fall into four buckets. UI: text that was not visible or clear. Presentation: information correct but not readable in practice. Missing fields: needs the mapping never caught. Process flow: logic the brief did not anticipate. Not one of these was visible in the garage. Every one appeared on the road.

I have seen operators stop at the build. The launch happens, adoption drops after two weeks, and the conclusion is that the system did not work. The system did not fail. The road was never laid.

Z for my business is AI-powered operations. Automated scheduling. Predictive compliance. Real-time field intelligence. That destination is real.

But A was where I stood when a guard called me about ₹500. Three verification layers had already confirmed there was no error. I had upgraded the gokart more than once. I had fixed real problems. I had concluded it was running. I could not see the workarounds my team had built to absorb the remaining gaps, until one slipped through.

B is O9X. Out of the garage, on the road. We fix it daily.

F1 will come or it will not. A Gokart on a real road, driven daily, is already a different business. It is not the one where a guard calls the founder to recover ₹500 buried in 50 unread messages.

Build the gokart first. Lay the road. Then worry about the engine.

For operators thinking about A, B, and Z: Reid Hoffman's ABZ Planning is worth reading. The project brief that preceded the O9X build is documented in my Build Log 8.