Sprint slots are open. Two clients at a time, because I build the fixes myself. See how the sprint works →

I learned troubleshooting on a meditation cushion.

Odd start for a data guy. Let me explain.

As a kid I practised Zen meditation. The first lesson is the only one that ever mattered: observe before you react.

Twenty years in IT taught me the same thing works on software.

  • The bug is rarely where the error appears
  • The slowdown is rarely the tool everyone blames
  • The fix is obvious only after you have seen the real problem

I started as a data analyst. I became the person companies called after everyone else had guessed wrong. At one point I was flown to the Atlanta office to untangle configuration issues nobody there could crack.

It was never technical genius. It was sitting with the problem longer than anyone else was willing to.

Same habit, different decade

The systems got more complex and the noise around AI made root-cause thinking rarer, not more common. Everybody is in a hurry to prescribe. Almost nobody stops to diagnose.

So the work I do now is the work I have always done. Someone tells me what is wrong. I go and find out what is actually wrong. Those are usually two different things.

A founder tells me his inbox is killing him and he needs an AI email tool. I ask why he is getting 80 emails a day. It turns out 30 are clients asking for status because nothing is visible, 25 are internal questions because nothing is written down, and 15 are scheduling because there is no booking link.

He did not have an email problem. An AI inbox tool would have helped him answer the wrong emails faster.

I don't trust things that look fine

I am also building Alacrio, a work assistant that watches your inbox and calendar for the things you would otherwise miss. Underneath it is Tarkavi, a reasoning and dispatch engine I built across six structured sessions: scaffold, reasoning engine, action dispatcher, memory and feedback loop, proactive scheduler, and a full security audit.

The audit was the point. It caught cross-tenant data leaks, missing auth checks, and race conditions. Bugs that never show up in a demo and always show up in production, usually at 2am, usually as somebody's angry email.

46 tests passing. Every one of those issues fixed before a single user touched it.

I am telling you this because it is the standard the consulting work is built to, not because it is a client result. It is not one. It is how I work when nobody is watching, which is the only useful thing you can know about someone you are about to hire.

What I can and can't show you yet

This consulting offer is new, and I do not have published before and after numbers from it. I am not going to invent them, and I am not going to write a composite client and present it as real.

What I have done instead is build the measurement into the work. Every sprint starts by measuring what the target workflow actually costs, in week one, agreed in writing. Then again at day 30 and day 90.

So the numbers are coming, and when they appear here they will be real ones with a method behind them.

Observe first. Fix second.

That order changes everything, and it is the whole reason this business exists. If you want to know where your own week is going, that is four minutes and it costs nothing.

Take the Manual Work Scorecard →