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

The mindset

I ran a Startmate mentor session in January on Claude Code and shipping fast. I opened with a line I repeat to myself: you do not 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.

Invert the question

Charlie Munger: invert, always invert. Do not ask how to ship faster. Ask what is making you slow.

For us it was usually one of these:

• Work blocked waiting on approval.
• Meetings that exist out of habit.
• Fear of shipping something imperfect.
• Vague ownership, where nobody owns the outcome.
• Optimising systems that do not need to scale yet.
• Too many projects, too much context switching.

None of that is technical. You fix it by changing the shape of the team, not by adding process.

The team shape that ships

The fastest teams I have been on shared a few things. One owner end to end, not 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.

Think to 80 percent, then ship

You do not need full confidence to ship. Just enough to know you are pointed roughly the right way, then get 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. Ship at 80 percent and course correct with data instead of opinions.

Building with Claude Code

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 the loop looks like this:

• Pick one tiny behaviour. Not a feature, a single user action.
• Ask for a plan before writing anything.
• When something breaks, paste the error, the context, the intent.
• Show the result to one user.
• Fix the first friction point, then repeat.

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

You do not need to make AI slop

AI output is not automatically low quality. But carelessness shows. People can tell when a product was generated and left unedited.

Generate a bad first cut, sand the rough edges, keep sanding until it feels right. The first draft is raw material. The craft is in the editing, same as always.

Give AI a good setup

AI works better with the right scaffolding around it. TypeScript gives it types to reason about. A linter and formatter like Ultracite keeps things consistent. Git lets you experiment and roll back. Logs give it context when it is 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.

Ship fast, rollback faster

Speed without safety is reckless, but safety does not have to mean slow. Bias towards action, ship small changes straight to main, and use pull requests for visibility, not as gates. If something breaks, roll it back.

Raise the quality bar only where mistakes are costly. Every standard costs a little speed, and that cost compounds.

Do not guess what is broken

Once you are shipping fast you need to see what is happening. Session replay, analytics, logs, alerts. Without them you are shipping fast and blind, which is worse than shipping slow.

Anyone can ship

The barrier to shipping a real product keeps falling. AI handles the parts that used to need deep specialisation. What is left is taste, clarity, and the willingness to put something in front of users before it is ready.

That last part is uncomfortable. It is also how every product I built that mattered got built.