The Right Way to Build Things is to Build Things

A few nights ago, I used the wrong pan to make dinner.

I was making a lovely stir-fry and our wok was dirty, so I improvised a little and used a frying pan to bring the magic. It was a little touch and go, but the stir-fry turned out how I was expecting (delicious). My evening with my partner though, didn't.

She was miffed off that I didn't use the "right" tool for the job, even though she hadn't realised I'd used the wrong tool until after dinner.

I bring this up, because it's this kind of thinking that is toxic in a startup.

After eight years in tech, you end up seeing the same patterns repeat themselves over and over. I've been part of software teams that are filled to the brim with really very smart people - but that failed anyway. Not because there wasn't a market for the product, or the timing wasn't right - but because the execution was off.

Execution is everything in startups; and the problem when you put a bunch of very smart people in a very small room and ask them to build a thing is, they often want to build that thing the "right" way.

You want to use the latest technologies, spend time mapping out the architecture, and perhaps spend just a few more months building an publish/subscribe pipeline so that your API will definitely be able to scale to the millions of users you know are right around the corner.

Sure it pushes the release date back by a few months, but this is the right way to do things.

But the secret in startups is this. There is no right way.

The only right way to build things is to build things.

Startups fail because they build products that make the tech team happy, but don't make the customer happy. They focus on developer happiness over customer happiness.

That six months of runway the company had? All gone trying to figure out Kubernetes clusters and arguing about the right name for a domain model, rather than say, I don't know, building a working product loved by the customer.

When Buffer got started, none of their potential customers ever asked to see their UML diagrams. No customer does. In fact they couldn't see them anyway, because Buffer started out as a landing page with zero lines of code.

People buy products that create value for them. That are delightful to use.

And sometimes if that value is insanely high enough they'll even forgive if the product is horrible to use (looking at you AWS). But for most startups (read you), this isn't the case. If your product is a bit rubbish, most people will bounce within the first seven seconds they're on it - even if it could scale to a million people.

As entrepreneurs we have a tendency to look at the heavy hitters, and try and reverse-engineer the same results. We look at the Facebooks, the Googles, the Twitters of the world. We see the struggles they had with scaling, and try to pre-optimize to avoid those issues.

But we're forgetting that first stage; Where Twitter was just a few people madly iterating on a product that had found market-fit. That had grown past the first dozen customers and was trying to handle hundreds of thousands of daily users.

That is when you should start thinking about optimisation. About the right way to do things.

I'm not saying you can't succeed building things that scale first. Monzo was built for scale from the get go, and that was probably the right approach for second-time founders with millions in VC cash before they had even decided on a name.

But if that doesn't sound like you, then it probably isn't. Most startups aren't born that way. As the Lean Startup puts it, a startup is an experiment. An experiment to test whether this idea is something people will really pay money for.

And the only way to test that, is to get something in front of real customers as quickly as possible - and not stop building until you have something that people love.