Your AI Rollout Starts With One Person. It Shouldn't Stay There.

Nobody warns you how lonely it is to be the one person actually trying to make AI work inside a company. That is where this issue starts, not with a framework, but with a feeling I heard about a dozen times this week from operators of every size. Everything else that happened (a startup you have never heard of raising $2 billion, Stripe buying a routing company for $7.5 billion, and the same six GTM gaps I still find in companies doing eight figures in ARR) points back to the same idea. The model was never the hard part. Neither is being the person who starts this. Rollouts almost always start with one person who has the technical chops and the resilience to push change through, and they only stay expensive when they stay there.

Why Does It Feel So Lonely to Be the One Carrying AI at Your Company, and What Actually Fixes That?

It is not because you are doing something wrong. Most companies treat AI as one person's side project instead of a coordinated effort, and that is the thing to fix, not your workload.

I have been the person who pitched the initiative, got a polite nod instead of the buy-in they were hoping for, and ended up being the strategy, the builder, the tester, and the one explaining why it is not live yet. I hear some version of that every single week, from five-person startups to enterprise teams. The titles change. The feeling does not.

Change management almost always starts with one person. Someone has to care enough to pitch it, build the first version, and absorb the first round of objections, and that person is usually the one with the most technical chops and the most tolerance for hurdles. That part is not the problem. The problem is what happens when nothing gets added around them.

What often goes unsaid is that the same person carrying the initiative is usually also expected to maintain the entire thing afterward, on top of their actual job, with no extra hours or headcount added to the calendar. A vibe-coded workflow or a quickly built agent does not stay working on its own any more than a car keeps running because you once changed the oil. It needs real upkeep: debugging when a model update quietly changes an output downstream, answering the same questions from three different teams, and pushing back on the agent with actual operator context when it produces something technically correct but operationally wrong.

That maintenance burden is real cost, even when nobody is tracking it as one. Every hour spent quietly babysitting a system that was supposed to run itself is an hour not spent on the next fix, and it is exactly the kind of invisible labor that inflates your true operating cost without ever showing up as its own line item next to CAC.

What breaks the stall is not a better tool. It is commitment from the teams around that one person. An executive sponsor who clears the budget argument. The process owner whose team actually does the work signing off on the change. Whoever controls the CRM or the warehouse granting access without a three-week queue. That is what turns a side project into a coordinated effort, and it buys three things a single builder cannot buy alone: shared buy-in, so adoption stops being a persuasion exercise; faster time-to-value, because access and decisions stop waiting; and a shared budget, so the upkeep is funded instead of absorbed.

The same signal is showing up at a completely different altitude. TechCrunch reported this week that OpenAI-backed Thrive Holdings raised $2 billion to bring AI into complex workflows like accounting and IT through hands-on implementation. That is a lot of capital chasing a fact that is easy to miss: every company's workflow is different, so AI has to be personalized to fit it. Even the biggest players in this space know their models alone will not get a team to the orchestration it needs. Layering AI onto a broken process just automates the leak, no matter how much capital backs the model underneath it.

If Fortune 500 companies need hands-on partners to make this work, a stretched team of five does not need to white-knuckle it alone either. You also do not have to tackle everything at once. Pick the highest-value problem. Map one workflow. Get one win the rest of the team can actually see. That is the moment the feeling flips from "why am I the only one who cares about this" to "we actually have momentum."

Related: what an AI implementation team actually looks like

If You Do Not Know Where to Start With AI, Where Should You Actually Look First?

Start with where the revenue is actually leaking, not with which model to buy. Everything else gets easier once you know that.

"Where do we even start" is the number one question I get from teams working on AI readiness, and honestly, it is the right question to be asking. Companies know their business is leaking revenue somewhere. They just cannot pinpoint where, mostly because founders are naturally removed from the under-the-hood problems while they are focused on high-level strategy. Deals stall. Leads sit in a queue too long. Handoffs between Marketing, Sales, and CS quietly break. When nobody can point to exactly where or when it breaks, the default move becomes "let's add AI" and hope the model figures it out. It will not. AI stacked on a broken process just automates the leak faster.

That is the exact gap I built Scan to close: a pre-sale revenue agent that starts with your website and works down, mapping where revenue is leaking across the GTM motion, which processes are actually broken versus just unscalable, and the one fix where process engineering should start first. Most teams do not need a 40-page audit listing every challenge in the business with no sense of priority or impact. What matters is starting small with one broken process and a step-by-step plan you can begin implementing that same day: which fix comes first, who owns it, and what "done" actually looks like.

What most teams miss is that AI readiness was never about picking the right model. It is about whether the environment around the model can hold up: clear processes, data you actually trust, defined ownership, and workflows written down instead of living in one person's head. Get those layers right, and adding AI stops being a leap of faith. Skip it, and you are paying to automate confusion.

Confusion has a pretty specific shape in most GTM stacks, and after enough of these conversations, I can usually spot it before someone even finishes describing their business.

Related: run a free revenue leak scan

What Are the Six GTM Gaps Quietly Creating Revenue You Cannot Explain?

Whether it is a brand-new app or a company doing eight figures in ARR, the same six gaps keep showing up, and none of them look like a bug until a board asks about numbers nobody can reproduce.

After 30-plus years around SaaS, the pattern repeats almost exactly the same way every time:

1. Product usage data that never makes it into the CRM
2. Trial-to-paid tracked as a monthly average instead of a cohort
3. Expansion conversations that only happen at renewal, when it is already too late
4. AI feature costs nobody is actually measuring
5. Founder-led sales that worked at $1M in revenue and breaks at $5M
6. Board reporting stitched together by hand every quarter

In 2026, shipping the product has never been faster, but GTM debt piles up just as fast, and most teams do not notice until they are explaining churn to a board that expected better numbers. Early-stage teams usually need to wire product data into the CRM first. Teams further along need cohort reporting and expansion triggers that fire off real usage instead of a renewal date sitting on a calendar somewhere. The best teams I have watched optimize are not chasing net-new logos. They are fighting for net revenue retention, and there is a reason that ratio matters more than logo count.

Fixing that debt is people-and-process work. But there is a bigger structural shift happening this week in how all of this actually gets paid for, and it is worth understanding before you sign your next AI tooling contract.

Related: what GTM debt is and who it affects

Is Token Routing About to Become the New Transaction Fee, and Why Should That Change How You Buy AI?

Stripe just paid roughly $7.5 billion for OpenRouter, a five-times markup in about 90 days, and the real story is not the price. It is the bet that token routing becomes its own toll road.

OpenRouter was the Zapier of LLMs: a single gateway routing traffic across 400-plus models so developers were not locked into one provider. Stripe is not buying a routing layer. It is buying the bet that token spend becomes the core economic unit of the AI era, and that whoever controls how tokens move between providers controls something closer to a toll road than a tool.

I wrote something that felt like a stretch about three months ago: that LLMs could end up competing with Stripe, Square, and the rest of the payment processing world, becoming the highways for how data moves and the moat holding infrastructure together, while software itself becomes free and the real value shifts to whoever is connecting the tools and moving the data. That starts to look a lot like a payment processor.

Highways are never free. And the quality of the transaction matters just as much as the routing itself: you do not want to pay for duplicate calls, failed transmissions, or messy handoffs, you want clean APIs, real SLAs, and guardrails making sure the system does what it is supposed to. That is the same idea behind picking the right model for a task instead of the most expensive one by default, just playing out at the infrastructure level instead of the individual workflow level.

Either way, the practical takeaway is not theoretical. If token movement starts behaving like a metered transaction fee, getting locked into a single provider is not just inconvenient anymore, it is a recurring toll with no leverage to negotiate down, on top of every other GTM cost already running through your stack.

Which brings the conversation back to the one metric everyone claims to be optimizing for, but which most systems still cannot calculate cleanly enough to actually trust.

Related: how to manage AI token costs

What Is Net Revenue Retention, and Why Do the Best GTM Teams Optimize for It Instead of Net-New Logos?

Net Revenue Retention (NRR) measures how much revenue you keep and grow from existing customers over a period, and above 100% it means expansion is outpacing churn and downgrades before a single new logo even closes.

The formula: NRR = (Starting ARR + Expansion − Downgrades − Churn) ÷ Starting ARR × 100. Most teams still report growth primarily through new-logo count, mostly because it is an easier number to celebrate publicly than a churn conversation. But new-logo growth without NRR context can hide that you are refilling a bucket that leaks. A company posting strong new bookings while NRR sits below 100% is spending real acquisition dollars just to stand still, and that shows up in your fully-loaded CAC the moment retained revenue actually gets counted honestly.

This is exactly where this week's GTM gaps come back around. Tracking trial-to-paid as a monthly average instead of a cohort smooths over the exact erosion NRR is designed to catch. Handling expansion conversations only at renewal means you are already too late to move the number that quarter. NRR is not a vanity metric sitting next to CAC, it is the other half of the same equation: CAC tells you what it cost to get someone in the door, and NRR tells you whether the business that got you there was ever actually worth having.

Full breakdown: what Net Revenue Retention is and why it caps CAC efficiency

What Do These Four Patterns Actually Cost You in CAC?

Each pattern above pulls on CAC from a different direction. Lined up together, they all come back to trying to fix too much, alone, without ever finding where the real leak lives.

1. Carrying AI alone: An initiative run by one person without commitment from the teams around them tends to solve the visible problem instead of the actual leak, and that same person usually becomes the system's permanent, unbudgeted maintainer after launch. The result: months of one person's time and credibility spent building something, followed by an open-ended, invisible maintenance cost that never touches CAC or LTV on paper but drains the hours that could.
2. Skipping the diagnostic: Without knowing where revenue is actually leaking, "add AI" becomes the default move, and it just automates whatever was already broken. The result: you pay twice, once for the original mistake and again for the tool that just scaled it.
3. GTM debt: None of these six gaps show up as a bug. They show up later as revenue nobody can explain or reproduce. The result: exactly the kind of number a board or investor digs into before the next check, at the moment you can least afford it to look shaky.
4. Token routing lock-in: If token movement becomes a metered, per-transaction cost, being locked into a single provider is not inconvenient, it is a recurring toll with no leverage. The result: a hidden line inside your true cost structure that scales with usage and quietly erodes the margin CAC efficiency depends on.

This Week's Move, starting Monday 8/24/26

Pick the loneliest AI initiative currently sitting on your plate, the one nobody else is really tracking, and do two things with it this week. Name the single highest-value problem, map one workflow around it, and ship one visible win the rest of the team can actually see. Then put a name next to each of the three roles you cannot cover yourself: who sponsors the budget, who owns the process, and who owns the data. Then check whether your NRR number would even catch the improvement if it worked.

Have a workflow, metric, or mistake you want broken down in a future issue? Reply to this or send me a DM on LinkedIn.