Why Your Solo AI Powered Projects Feel Fast (And Your AI-Powered Software Team Doesn't)
Everyone building software with AI on their own is having the same realisation: this is how building software should actually work.
You form an idea, you build something, you try it, you know straight away what’s wrong, you iterate. The loop closes in minutes. The product gets better fast. There’s no handoff, no waiting, no miscommunication. It feels obvious. It feels right.
And then you look at your software team and wonder why they can’t move like that.
The reason building software with AI in “single-player mode” feels so good isn’t just that AI is fast. It’s that the learning loop is fast. AI removed the build-time bottleneck that used to make solo work too slow to be viable. The loop was always the right model. We just couldn’t run it solo at speed before.
Great software teams have always known this. They stay tight, stay close to users, and iterate constantly. The reason they’re great is that they’ve engineered a fast feedback loop between idea, build, user, and decision. Single-player mode is now a model version of that loop. One head, no handoffs, nowhere for the context to leak.
The temptation right now, the one I’m watching product leaders fall into, is to copy the wrong thing. They see and experience single-player mode moving quickly and think we need to ship faster. So they drive the team to generate features at velocity. They produce confident-looking mediocrity at a rate no team could match before. The dashboards look healthy. The product gets worse.
They copied the speed. They didn’t copy the learning loop.
The whiteboard version
Here’s how I’d draw this if someone asked me what to do.
Two questions matter for any team:
- Are you travelling in the right direction?
- Are you travelling fast?
Two metrics answer those questions. They’re coupled but distinct, and both have to be present.
“The output metric tells you whether you’re winning. Learning loop speed tells you how fast you’re learning how to win.”
Direction: The initiative output metric
Every initiative needs one number it’s trying to move. One. Activation, retention, conversion, and operation efficiency, compliance. Whatever it is for that specific work. That number is your direction. I like them to be tied to the business’s commercial outcomes, so you can draw a line to revenue, expenses, or risk.
Three rules:
- One metric per initiative. Not three. Not a balanced scorecard. One.
- Someone owns it. A person, on a team. They’re accountable for moving it.
- Every epic under the initiative either drives that number or it doesn’t belong there. If it doesn’t drive the number, split it out into a different initiative with its own metric.
This sounds simple. It’s not. Most teams have initiatives with no clear output metric, or three competing ones, or a metric nobody actually owns. When that happens, the team can’t tell whether the work is moving anything. Every epic gets justified on its own terms. And speed without direction is sprawl. And now we can get sprawl at the speed of AI.
There are three other types of metrics worth tracking, but none of them replaces the output metric:
Input metrics are the parts that add up to the output. If your output metric is weekly active users, your inputs might be sign-up conversion rate, time-to-first-value for a new user, and return-visit rate in the first week. They tell you how you’re moving the output number. They roll up to it. If the inputs are moving but the output isn’t, something about how they combine is wrong. Time to revisit the model.
Side-effect metrics are good things you expect to happen because of the output moving. Satisfaction. Retention. Referrals. Downstream commercial effects. Treat these as signals, not targets. If they’re moving alongside the output, great. If they’re flat while the output is moving, ask why before celebrating.
Health metrics are guardrails to keep you from breaking something else. Churn, errors, and time using a feature. If a health metric goes the wrong way, stop and investigate before pushing harder on the output. Achieving your output metric while breaking something else isn’t winning.
The output metric is the only one you optimise for. Everything else is context and side effects.
Speed: learning loop speed
Once you have direction, you measure speed. Not velocity. Not features shipped. Learning loop speed.
A learning loop starts when the team picks up a hypothesis, a belief about what users need to move your output metric (or one of the input metrics that roll up), and ends when the team has tested it with real users and made an explicit decision: persevere, pivot, stop, or kill.
Persevere: it’s working, keep going. Pivot: it’s partly working, but we need to change direction. Stop: we’ve won enough on this metric, or we’ve run out of time, or the business has redirected us elsewhere. Kill: it’s not working, walk away.
Open hypotheses sitting in a backlog don’t count. Iterations that loop forever without a decision don’t count. Only closed loops count.
Three things to track per loop:
- Time from pickup to first user contact
- Time from user contact to decision
- The persevere / pivot / kill ratio
That last one matters because if every loop ends in persevere, you’re not being honest about failures. Or you’re genuinely amazing. If every loop ends in kill, you’re not committing to anything, or you’re missing important information. A healthy team has a mix.
Learning loop speed is the primary output metric for the team itself. Everything else. Velocity, design cycle time, deploy frequency, those are team input metrics. They matter because they feed the loop speed. But on their own, they tell you nothing. A team can ship fast and learn nothing. A team can be busy and going nowhere.
Why both, and how they multiply
The output metric tells you whether you’re winning. Learning loop speed tells you how fast you’re learning how to win.
Loop speed multiplies everything else. Bets per cycle 𝒙 quality of feedback per bet 𝒙 amount you are moving the metric = expected value delivered.
If your loop speed is healthy and your initiative metric isn’t moving, you have a strategy problem. You’re learning fast, but you’re pointing at the wrong mountain. Change direction.
If your initiative metric is moving but your loop speed is poor, you got lucky, and it won’t last. You’re climbing the right mountain, but you haven’t built the muscle to keep finding right mountains.
If both are healthy, you compound. That’s the goal.
Where AI actually fits
AI compresses the build phase of the loop. That’s its real contribution. It doesn’t directly move your initiative metrics. It can’t make users want your product more. What it does is let you get from hypothesis to testable faster, which increases loop speed and the rate at which you find things that move the initiative output metric.
AI is a multiplier on learning velocity. Not on outcomes.
The trap is using AI to skip the loop entirely. Generate the feature, ship it, move on. That produces sprawl, not learning. The software discipline of iterative learning was never really optional, but sometimes overlooked. Longer build times with higher costs naturally slowed teams down enough to think about what they were delivering. The loop is now more important than ever, precisely because building is fast.
Single player mode is the proof. Solo, you act as PM, engineer, designer, QA, and often also the user. AI unlocked solo development because it collapsed the build phase, so you can learn, deliver, and iterate fast. A single-player game is a model of how multiplayer needs to work. Measuring loop speed drives the team to optimise feedback speed, which drives velocity in the right direction.
The discipline
Single player mode with AI has revealed what good looks like. The discipline is to copy the loop, not the speed.
- Define the output metric for each initiative. One number. Someone owns it.
- Measure your team on loop speed. Track closed loops per cycle. Track time from hypothesis to decision. Track the persevere / pivot / kill ratio.
- Treat velocity as an input. It matters because it feeds the loop speed. But it’s not what you optimise for.
- Stay cross-functional and tight. Product, design, engineering, user. They don’t have to be one person, but they have to talk constantly. Loops die at handoffs.
- Use AI to compress the build phase, not to skip the loop. Cheap building is exactly why validation matters more, not less.
If you do those things, your team will start to feel like single-player mode at scale. Fast in the right direction. Learning out loud. Shipping things that actually move the number.
If you don’t, you’ll just generate sprawl faster than you ever could before.
That’s the choice in front of every team right now. Single player mode showed everyone what’s possible. The question is whether teams will copy what makes it work, or just copy the speed and miss the system underneath.
Enjoyed this post? Leave a comment or like it on Substack.