You do not win by being right. You win by finding out faster.

I ran a Startmate mentor session in January on Claude Code and shipping fast. I opened with the line I repeat to myself: you don’t win by being right, you win by finding out faster.

Most teams treat being right upfront as the goal. Weeks scoping, debating architecture, polishing Figma, aligning stakeholders. By the time they ship, the market has moved or nobody wanted it.

At Fingertip and VenueSafe we shipped early, watched real users, and iterated hard. Speed was survival.

The shape of a fast team

Charlie Munger: invert, always invert. Don’t ask how to ship faster. Ask what’s making you slow.

For us it was usually one of a few things, none of them technical. Work blocked waiting on approval, meetings that existed out of habit, fear of shipping something imperfect, vague ownership where nobody owned the outcome, optimising systems that didn’t need to scale yet, too many projects and too much context switching. You fix that by changing the shape of the team, not by adding process.

The fastest teams I’ve been on shared a few things. One owner end to end, rather than a chain of handoffs between product, design, and engineering. Fewer meetings. Small, because communication overhead scales quadratically. A clear definition of done, or everything sits at 90 percent forever. And the builder close to the user, because secondhand feedback loses texture.

The Claude Code loop

AI changed the speed equation for me, not because it writes perfect code but because it compresses the feedback loop. Claude Code writes, I review, I give feedback, it iterates. Dozens of times in an hour.

When I start something new I pick one tiny behaviour, not a feature but a single user action, and ask for a plan before anything gets written. When something breaks I paste the error, the context, and the intent. Then I show the result to one user, fix the first friction point, and go again.

It builds in layers, which matches how I think about product anyway. Start with a Wizard of Oz where nothing behind the surface is real. Then a low-fi UI in code, the data model, the API, the back end, and front-end polish last. Each layer ships and gets tested on its own.

The loop only runs that fast with the right scaffolding around it. TypeScript gives it types to reason about. Ultracite keeps the formatting and linting consistent. Git lets you experiment and roll back. Logs give it context when it’s debugging.

If AI finds a change hard to make in your codebase, take the hint. The coupling slowing it down is slowing your humans down too.

Shipping at 80 percent

You don’t need full confidence to ship. Just enough to know you’re pointed roughly the right way, then real signal from real users.

The last 20 percent of certainty is the most expensive and the least useful. Teams burn weeks on edge cases that never happen.

Speed without safety is reckless, but safety doesn’t have to mean slow. I ship small changes straight to main and use pull requests for visibility rather than as gates. If something breaks, roll it back. Raise the quality bar only where mistakes are costly, because every standard costs a little speed and that cost compounds.

You do need to see what’s happening once you’re moving that fast. Session replay, analytics, logs, alerts. Without them you’re shipping fast and blind, which is worse than shipping slow.

The barrier to shipping a real product keeps falling, and AI handles more of the specialised work every month. Putting something in front of users before it’s ready still feels wrong.

It’s also the only way I’ve ever found out anything that mattered.