I joined my current startup as a founding engineer after spending years at large organisations—first at Airbus, and then at VMware (now part of Broadcom).

One of the biggest mindset shifts was understanding what “speed” really means in an early-stage startup.

A startup that hasn’t yet found product-market fit must constantly validate its product and assumptions with potential customers. Investors may fund the vision, but they don’t decide whether you’ve built something valuable.

Customers are where the rubber meets the road.

That makes the journey from a proof of concept to a production-ready product critically important. Early on, every customer counts. Every deployment, conversation, and piece of feedback helps answer one question:

Are we solving a real problem?

This is where YAGNI (“You Aren’t Gonna Need It”) becomes more than engineering advice—it becomes a business strategy. I eventually learnt to resist building for hypothetical future requirements. Build what today’s customers need, learn from their feedback, and iterate.

Two Kinds of Speed #

Coming from large organisations, I thought speed meant engineering throughput: how quickly features were implemented, reviewed, tested, and shipped. (In a large company, shipping something in a quarter can feel fast.)

In a startup, that’s only one dimension.

The more important speed is learning speed: how quickly you discover whether you’re building the right thing. While engineering speed reduces the time from idea to deployment, learning speed reduces the time from deployment to insight.

The first optimises execution. The second optimises direction.

I found that once we had a few customers using the product, their feedback became more valuable than our assumptions.

A team can have excellent engineering velocity and still spend months building features nobody wants. A team that ships small, focused increments learns faster, changes course sooner, and ultimately builds a better product.

Speed vs. Quality #

The first objection to moving quickly is usually, “Won’t quality suffer?”

I have learnt (the hard way) that it’s the wrong trade-off. The goal isn’t to sacrifice quality for speed. It’s to be deliberate about where quality matters. For example, if a bug causes a customer to lose data, that’s unacceptable. However, if a feature is implemented in a straightforward way instead of through an elaborate abstraction for imagined future use cases, that’s often the right decision.

With the advent of AI tools, writing code has become easier and faster. It has become very obvious that speed wasn’t about how fast we could ship code. It was how fast we could replace assumptions with evidence.