All founders want their time back. They started the company to grow it, not to become the thing it runs through.
2026 gave them their first peek at it. IF they set up their infrastructure for growth correctly.
I sat down with 30 founders this year, across every kind of industry. Every one of them saw how fast, cheap and real their growth plan could now be. And every one of them, sooner or later, said some version of the same sentence:
“We aren’t moving as fast as I think we can.”
That sentence is the whole reason this post exists. It sounds like a complaint about speed. It’s actually a complaint about time, and about who in the business is spending it.
Two Kinds of Founder, One Blind Spot
The founders split cleanly into two groups, and both groups were stuck for opposite reasons.
The hands-on founders knew how everything worked. Every SOP, every workaround, every customer quirk lived in their head.
Great for understanding SOPs. Poor for scale.
This meant they were too close to the issues, and spent their own time outperforming the people they hired to do the job. Every hire came with a founder checking the work behind them, because the founder was the only one who knew what “right” looked like.
The hands-off founders were the opposite. They had built a team, stepped back, and couldn’t tell you the SOPs of their own business or how the work actually got done.
Great for scale. Poor for AI.
This meant they were too far from the issues to see what their team needed, so they couldn’t give their team more capacity. You can’t put agents on a process nobody has written down.
Different operating styles. Same sentence.
What “Not Fast Enough” Actually Means
When I dug in, the sentence broke into four smaller ones. I heard them so often I could finish them myself:
“We do marketing, but I’m not sure it’s working as well as it can.”
“We have a forecast, but I’m not sure I can trust it.”
“We have a pipeline, but I’m not sure these are really our buyers.”
“We have operations scaling our services, but I think we can be doing a better job.”
Look at the shape of those. Every one is “we have the thing, but I’m not sure.”
The marketing exists. The forecast exists. The pipeline exists.
What’s missing is trust in the output, and when a founder can’t trust the output, they check it themselves. That’s where their time goes.
(The pipeline one deserves its own post, and it has one: your ICP isn’t broken, it’s undocumented.)
People, Systems, Software
As I unravel those questions, the gaps show up in the same three places every time. I ask one question about each.
You hear the people are doing things. Are they doing them efficiently? Could the same work take a fraction of the time?
You hear systems are in place. Do those systems evaluate the outcomes of the process, or do they just record that the process happened? Is anything adjusting in real time toward the goal?
You hear the software was built around the process. Is the process working? And where are the gaps in that software, the ones a person quietly fills by hand every week?
Then the question that turns the conversation:
What is the annual OPEX on all of it?
The Age-Old Pattern
That last question is where the pattern lives. It’s the same pattern almost every growing company follows, because for a long time it was the only option:
Buy software, train people, get caught on upsells that turn into recurring OPEX. Repeat.
Every round of that loop adds a line item that never goes away.
Seats grow with headcount. Usage tiers grow with success. The renewal shows up whether the tool earned it or not.
And every round costs founder time too: another vendor to manage, another training cycle, another place where the truth about the business lives.
That last one is the expensive one. Every new source of truth is another dashboard someone has to reconcile before anyone trusts it. That’s how you end up with “we have a forecast, but I’m not sure I can trust it.”
The tooling is everything. The question is who owns it.
What Owning It Looked Like on One Build
Here’s one engagement from this year, with the client anonymized.
A growth-stage software company was one signature away from a per-seat agentic CRM. At their seat count, the equivalent stack ran about $315K a year at list price, and it grew with every hire they made. The fine print made it worse: exceed your credit allocation and you pay a premium on the overage.
We built the equivalent instead:
- $102KBuilt once. Two products on one shared agent system, deployed into their own GitHub org on day one.
- 7 daysFrom kickoff to handover. They’ve run it themselves since.
- $110 / monthIn model usage. Billed directly to their own model account. No per-seat math, no vendor markup.
- ~$212KIn their favor in year one. And the gap widens every quarter they hire.
Their GTM lead put it better than I can, six months in: “The orchestrator is doing the work of two hires we didn’t make.”
Same team. More output. That’s the outcome I care about most. (The full build is written up here.)
None of this works if you start with the build. It works when you start with the process, which is why we start with questions before agents, every time.
Never Have We Been in a Time Where
I keep coming back to this, because it’s genuinely new. Never have we been in a time where, all at once:
- 1A new solution saves costs. It costs less than the software it stands in for, instead of stacking on top of it.
- 2A new solution lets people do more. Same team, more output. The two hires you didn’t have to make.
- 3A new solution is built from how your business ACTUALLY runs. Your SOPs are the spec. The agents follow your process instead of making you adopt theirs.
- 4A new solution carries less training debt than the last one. The agents work inside the tools your team already uses, so there’s no new system to teach everyone.
Every previous wave of business software gave you one or two of those at the cost of the others. This is the first time all four line up.
What AI Transformation Actually Means
The phrase gets thrown around enough that it’s lost its meaning, so here’s mine.
AI transformation is rolling your own agent layer: built on your SOPs, integrated into your environment, running on a model account you control, with code that lives in your repo. You rent the model. You own everything around it.
It is not another subscription with a chat window bolted to the side.
The Point Is Time
Here’s what I didn’t expect when I started having these conversations. For both founders, the solution boiled down to the same layer.
The hands-on founders’ SOPs finally live somewhere other than their head. The layer holds the standard and checks the work against it, so they stop outperforming the people they hired.
The hands-off founders finally see what their team needs. The layer measures what the process produced, not just that it ran, so they can see it without running the work themselves.
Opposite problems, same fix. Both get their time back.
Both get their time back. That’s the point.
Lower OPEX is real, and the integration is real.
But the founders I talk to don’t want a cheaper stack for its own sake. They want to stop being the bottleneck in the company they built.
An Honest Invitation
Our 2026 calendar is full, so we run a queue for 2027 engagements. If you’re hearing that sentence in your own head (“we aren’t moving as fast as I think we can”), the queue is free to join. Tell us the workflow that eats the most of your time, and that’s where the conversation starts.
The rest of the field notes walk through how these systems actually get built.