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

The mindset

I ran a session for the latest Startmate cohort and opened with a line I repeat to myself: you do not win by being right. You win by finding out faster.

Most teams operate like being right upfront is the goal. Weeks scoping, debating architecture, polishing Figma, aligning stakeholders. By the time they ship, the market has moved. Or they built something nobody wanted.

At Fingertip and VenueSafe, the pattern was the same. We shipped early, watched real users, and iterated hard. Speed was survival.

Invert the question

Charlie Munger: invert, always invert. Instead of asking how to ship faster, ask what is making you ship slow.

The usual culprits:

• Blocked work waiting on someone else's approval.
• Meetings that exist out of habit.
• Fear of shipping something imperfect.
• Vague ownership where nobody is responsible for the outcome.
• Premature optimisation on systems that do not need to scale yet.
• Context switching across too many projects.

Most of these are not technical. They are organisational drag. You fix them by changing the shape of the team, not by adding process.

The team shape that ships

The fastest teams share a few traits. One owner end-to-end, not a chain of handoffs between product, design, and engineering. Fewer meetings, because meetings are where momentum dies when there is nothing specific to decide. Small teams, because communication overhead scales quadratically. A clear definition of done, because without it everything stays 90 percent finished forever. The builder stays close to the user, because secondhand feedback loses texture.

With those conditions, speed becomes the default.

Think to 80 percent, then ship

You do not need full confidence to ship. You need enough to know you are pointed in roughly the right direction. Then you need signal from real users.

The last 20 percent of certainty is the most expensive and least valuable. Teams burn weeks debating edge cases that may never happen. Ship at 80 percent, learn what matters, and course correct with data instead of opinions.

Building with AI

AI changed the speed equation. Not because it writes perfect code, but because it compresses the feedback loop. With Claude Code: AI writes, I review, I give feedback, it iterates. That loop can happen dozens of times in an hour.

The workflow for building something new:

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

AI builds in layers, which matches how I think about product. Start with a Wizard of Oz where nothing is real behind the surface. Then a low-fi UI in code. Then the data model, API, back-end. Finally, polish the front-end. Each layer is shippable and testable 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.

Three steps. Generate a bad first cut. Sand the rough edges. Keep sanding until it feels right. The first draft from AI is raw material. The craft is in the editing, same as always.

Give AI a good setup

AI works better with the right infrastructure. TypeScript gives it type safety to reason about. A linter and formatter like Ultracite means consistent code without manual cleanup. Git means you can experiment and roll back. Logs give it context when debugging.

If AI finds changes hard to make in your codebase, that is a signal. Your architecture has coupling problems that are slowing 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 directly to main, and use pull requests for visibility, not as gates. If something breaks, roll it back.

Raise the quality bar only when mistakes are costly. Do not add process prophylactically. Every standard has a cost in speed, and that cost compounds.

Do not guess what is broken

Once you are shipping fast, you need to know what is happening. Session replay, analytics, logs, and alerts are not optional. They are the infrastructure that makes speed sustainable. Without them, you are shipping fast and blind, which is worse than shipping slow.

Anyone can ship

The barrier to shipping a real product has never been lower. AI handles the parts that used to need deep specialisation. The constraint now is taste, clarity, and willingness to put something in front of users before it feels ready.

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