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

The mindset

When I ran a session for the latest Startmate cohort, I opened with a line I have repeated to myself more times than I can count: you do not win by being right. You win by finding out faster.

That sounds obvious, but most teams operate as though being right upfront is the goal. They spend weeks scoping, debating architecture, polishing designs in Figma, aligning stakeholders. By the time they ship, the market has already moved, or worse, they built something nobody actually wanted.

At Fingertip, which was acquired by Linktree, and at VenueSafe, which was acquired by me&u, the pattern was the same both times. We shipped early, watched real users, and iterated hard. Speed was not a nice-to-have. It was survival.

Invert the question

Charlie Munger had a line I keep coming back to: invert, always invert. Instead of asking how to ship faster, ask what is making you ship slow.

In my experience, the usual culprits are predictable:

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

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

The team shape that ships

The fastest teams I have worked on 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 goes to die 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. And the builder stays close to the user, because secondhand feedback loses the texture that matters most.

If you have those conditions, speed becomes the default instead of something you have to fight for.

Think to 80 percent, then ship

This is the principle I push hardest. You do not need full confidence to ship. You need enough confidence that you are pointed in roughly the right direction, and then you need real signal from real users.

The last 20 percent of certainty before shipping is almost always the most expensive and least valuable. It is where teams burn weeks debating edge cases that may never materialise. Ship at 80 percent, learn what actually matters, and course correct with data instead of opinions.

Building with AI

AI has changed the speed equation dramatically. Not because it writes perfect code, but because it compresses the feedback loop. The cycle I use with Claude Code looks like this: AI writes the code, I review it, I give feedback, it iterates. That loop can happen dozens of times in an hour.

The practical workflow for building something new with AI is straightforward:

• 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 also likes to build in layers, and this matches how I think about product development. Start with a fake version, a Wizard of Oz where nothing is real behind the surface. Then build a low-fi UI in code. Then add the data model, the API contract, the back-end logic. Finally, polish the front-end. Each layer is shippable and testable on its own.

You do not need to make AI slop

One thing I wanted the cohort to hear clearly: AI output is not automatically low quality. But carelessness is always visible. People can sense when a product was generated and left unedited.

The process I follow is three steps. Generate a bad first cut. Sand the rough edges. Keep sanding until it feels right. The first draft from AI is never the finished product. It is raw material. The craft is in the editing, the same way it has always been.

Give AI a good setup

AI works dramatically better with the right project infrastructure. TypeScript gives it type safety to reason about. A linter and formatter like Ultracite means it produces consistent code without manual cleanup. Version control through Git means you can experiment freely and roll back when something goes wrong. Logs give it context when debugging.

If AI finds changes are hard to make in your codebase, that is a signal. It usually means your architecture has coupling problems that are slowing down humans too.

Ship fast, rollback faster

Speed without safety is reckless. But safety does not have to mean slowness. The approach I use is to bias hard towards action, ship small changes directly to main, and use pull requests for visibility rather than as gates. If something breaks, roll it back immediately.

Raise the quality bar deliberately and only when mistakes are actually costly. Do not add process prophylactically. Every standard you introduce 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 actually 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 core message I left the Startmate cohort with is simple. The barrier to shipping a real product has never been lower. AI handles the parts that used to require 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 have built that mattered actually got built.