We don’t build software. We offload cognition.

The lie I started telling after we got good

When Tony and I first started OpsKings, we were gentle with expectations. A founder would come to us with some kind of hybrid business, a hockey league that also sold custom merch on the side, some weird vertical nobody else served, and we’d say honestly, “I don’t know what this whole thing looks like yet. Here are the next few steps. These steps will help. Beyond that, I can’t promise you a huge outcome.”

Nobody wants to hear that. Clients want certainty. But we genuinely couldn’t give it to them, so we didn’t, and we naturally fell into a rhythm of sprints, small, staged, iterative work.

Then we started getting testimonials. Real ones, big ones, people who scaled hard. Clients would come in and say, “I saw what you built for so-and-so. Can you just give me that thing? I want that.” And we got a little cocky. We started saying yes.

That’s when the results got worse.

For a long time I thought this was a skill issue on my end. We have a process called the company brain where we visually map a client’s entire operation before we build anything. I kept thinking, I just need to get better at asking questions in the company brain phase. Then I’ll extract the perfect set of requirements, and of course we’ll build a perfect system, and there’ll be no feedback, no missed details, nothing.

I was pissed at myself. We have forty-something testimonials now, and I’m pissed we don’t have a testimonial plus infinite referrals plus millions of dollars from every client. That’s just how I’m wired.

Then I figured out what was actually going on. And it wasn’t a requirements problem.

There are layers of process, and almost nobody sees their own

When a founder walks into our company brain session, they have a declared process, the version of the business they can articulate if you ask them to describe it. It’s maybe 30% of what’s actually happening.

As soon as we start drawing it, visually, in front of them, as they describe it, more of the process surfaces. Every single time we do this, founders tell us the session felt like therapy. “Oh, I forgot about this piece.” “Actually, there’s this exception.” “Wait, we do this other thing for certain clients.” When the process is outside their brain and on a canvas they can see, they recall more of it.

So at the end of company brain, we have maybe 60% of the real process documented. That’s a huge leap. And for a while, I thought that was as far as this surfacing effect went, company brain, done, requirements locked, go build.

It was a much bigger effect than I realized. Every stage of implementation surfaces more process. And the founder doesn’t know that’s going to happen, so when they see our first working system and say “oh, you missed this, and this, and this,” it feels like we screwed up requirements. It isn’t. It’s their brain releasing stored cognition now that part of it has somewhere else to live.

Why I won’t build on top of ClickUp

For years we’ve had a policy, OpsKings will not build on top of ClickUp. Or Asana, Basecamp, Monday, Google Sheets. If you love ClickUp and want to keep it, you should go somewhere else, spend fifty grand, watch it not work, and come back after.

That sounds harsh. We’ve said no to a lot of business this way. For a long time, I knew it was the right call but I couldn’t articulate why. Now I can.

Flexible project tools are coordination surfaces. They let you track work, but they don’t take any work off the humans using them. Every rule still lives in someone’s head. Every “remember to do X” is still a burden on a person. You can layer SOPs on top, but the SOPs live in a doc nobody reads.

That’s not offloading cognition. That’s just relocating it to a more organized place in the same brain.

What we actually build is different. The system enforces the logic, the next step literally can’t start until the previous step produces its output. The rule isn’t something a person remembers. The rule is the path. That’s what starts taking weight off the team’s brain.

You can’t do that on top of a flexible tool, because a flexible tool will always let you work around it. And the moment it lets you work around it, the cognition goes right back into the human.

The 95% failure rate is a symptom of the wrong goal

There was a New Yorker article recently that reported something like 95% of companies trying to implement AI have failed at it. That number gets thrown around as a problem with AI. I don’t think it’s a problem with AI at all. I think it’s a problem with the goal.

Most companies approach AI and automation the same way they approach any project, they write requirements, they scope a tool, they hire someone to build it, they expect a finished thing at the end. Tech-as-deliverable. Build tech, ship tech, done.

Our job isn’t to build tech. Our job is to make your job and your company’s job easier so you can scale. Sometimes that means building something new. Sometimes it means tweaking something that already exists. Sometimes it means explicitly saying no to a client’s request because there’s a non-tech way that has a better result with less effort. Sometimes it means telling a client, honestly, that they don’t need more software, they just need to go scale.

If you scope an AI project as “build this tech,” you’ll probably build the tech. And you’ll probably be part of the 95%. Because the tech got built but the cognition didn’t move.

The goal is never tech. The goal is to take the repetitive knowledge work happening in your team’s brains and move it somewhere else. Sometimes that involves software. Sometimes it involves deleting a process. The work is cognitive, not technical.

Why offloading thinking has to happen in stages

Here’s the part I wish I’d understood two years ago.

Offloading cognition works the way learning works. You can’t go from zero to fluent. You learn to swim in shallow water before the deep end. You ride a bike with training wheels before without. You trust a little, succeed a little, get trusted with more.

Client teams unlearning how to think about their own process works the same way. You can’t take a founder who’s been running everything in their head for six years and in one month transplant all of it into a system. Even if the system is technically capable of holding it, the founder isn’t capable of letting go of it that fast. Neither is the team.

So what actually works is staged. We build less than the client wants, slower than the client expects. We show them the first version. They look at it and say “oh, you missed this, I just thought of this, we also do this thing.” And the moment of disappointment I used to feel on their behalf, we screwed up requirements, is actually the exact thing we were trying to produce. Their mind released cognition, and now new thoughts can surface.

It’s the same effect as taking a shower, washing the dishes, going for a walk. When your mind isn’t being bombarded by the stuff you normally hold, you get clarity. You see things you couldn’t see before. The ideas don’t arrive because you tried harder, they arrive because you made room.

This is why a scaling business never feels “done.” And it shouldn’t. If your system feels done, either you’ve stopped growing or you’ve stopped noticing. The forty clients we have testimonials from are people who embraced the sprint process and kept going. The ones I’m less happy with are the ones we promised a defined outcome to, on a defined timeline, because they pattern-matched against someone else’s finished-looking case study.

What this means if you’ve tried automation before and it didn’t stick

If you’ve hired an automation consultant or a no-code builder before, and they clearly knew how to build things, but somehow the ROI never landed, your team didn’t trust it, you didn’t feel like scaling got easier, you quietly went back to spreadsheets, I think this is probably why.

The tech got built. The cognition didn’t move. Those are two different projects, and most firms are only running the first one.

Here’s the part that’s genuinely encouraging to me, despite all of it. Even if you don’t think your business can be automated, even if your delivery is all bespoke, all artisan, all human judgment calls, I guarantee there is repetitive thought happening in your team’s brains that doesn’t have to be happening there. The coordination between tasks. The remembering of client context. The chasing of status updates. The mental model of what’s due when. None of that has to live in a human.

You can keep every task a manual execution and still offload the thought that coordinates the tasks. We’ve had clients who do almost no automation of tasks but an enormous amount of automation of thought, and the result is founders taking three-week holidays for the first time in nearly a decade. Everything ran without them because the coordination wasn’t in anyone’s head anymore.

That’s the thing to want. Not a finished product. Not a perfect requirements doc. Not tech for tech’s sake. A business that keeps releasing thought from your team, stage by stage, for as long as you’re growing. Which, ideally, is forever.

To anyone we worked with who didn’t get there

If we worked together and you didn’t leave a testimonial, I’m sorry. I wish I’d had the words to tell you, on day one, that the result we were trying to produce was offloading cognition, not building software. That the feeling of “oh, you missed this” was the process working, not failing. That going slower and building less was the point, not the problem.

I didn’t have those words. I have them now. That’s what this essay is.

If you’re considering hiring us, or anyone, to implement systems, AI, or automation in your business, the question to ask isn’t “how fast can you build this?” The question is “how much thought can you get out of my team’s heads, and in what order?”

If the answer is a confident timeline and a finished-looking deliverable, run. Nobody can promise that, and the people who do are going to ship tech that nobody trusts and nothing runs on.

If the answer is “we’ll start small, we’ll go slower than you want, and every stage will surface things neither of us can see yet”, that’s the real work. That’s what scales businesses. That’s what I should have been telling clients from the beginning.