The Full Build Startup

For a certain type of company, MVP just doesn't cut it. You need to start with more. You need "Full Builds".

Nearly all startup advice is for Minimum Viable Product – or MVP–driven startups. You start small. Get something real in front of customers ASAP. You learn. You iterate. The idea is to reduce risk. To Build Something People Want. But for a certain type of company – what we’ve ended up calling “Full Builds” – you need to start with more.

Equals – our company – is a Full Build. We’re building a next-generation spreadsheet. To have any shot at competing with the existing players, we need to build a programming language, a virtually rendered infinitely scrollable sheet, a cell editor, pivot tables, charts, full multi-player editing, and a full formatting system. Oh, and it all needs to be really fast. When Bobby and I went out to raise our seed round in 2021, multiple people told us what we were attempting was simply impossible. Can’t be done. Not with less than thirty people anyway, and it’ll probably still fail. So – how did we do it?

Well, it helped that I failed once before.

A Full Build, MVP Style

In 2017, I co-founded an email startup called Consider. Consider was a new email client built to compete with Slack. After a few years of building and having gotten little traction, we made the decision to shutdown. Email clients and spreadsheets are difficult in different ways. But there is one important commonality: both of these products require building an awful lot before doing anything new. They’re Full Builds.

Planning was a good chunk of Consider’s failure. We should’ve had a map of all the things we needed to build up front. We knew Consider was a large undertaking. To write that all out – to put together a 9-month or 12 month plan for building our V1. It went against everything anyone would tell us about building a company. So we didn’t. I thought building iteratively would let us build less, maybe skip some email features that weren’t too important, and get something in front of people sooner.

Yet our even bigger mistake was changing things not core to our thesis. We changed things like how conversations were defined, how the inbox worked, and how emails were presented. You’ve got to spend months building this thing anyway, and we’re smart product people? Why wouldn’t we make it better?!

Consider launching with a bang. Our waitlist grew to thousands of people overnight. People loved our brand and how we spoke and thought about email. But once people started using the product, they realized we were missing table-stakes features like spellcheck, labels, and snooze. Even worse, no one could use the thing! Any meaningful innovations in the product were obscured by how different it was.

A single bet strategy

The problem with Consider was not the amount we built. It was the risk we introduced by changing so much. The biggest risk in building a product is new ideas. New ideas are bets. They’re bets that people work a certain way or think a certain way, or feel a certain way. And what I’ve learned the hard way is the success of a product is not defined by the sum of its bets but rather by the product of its bets. Bad bets drag the whole thing down. Consider had so many wrong bets the whole thing became immovable. We couldn’t just ship a game-changing feature to win over users, we could only fix the product by starting from scratch.

When starting Equals, I started hearing all the same things as before. You’re building too much. Why don’t you start with a plugin instead? You’ve got to get out there and learn! What we needed for Equals to work was not a recipe for building less. We knew deep down that we had to do the Full Build. What we needed was a way to reduce the risk in building so much. So, we came up with three rules to keep us on track.

First, make a detailed plan. We weren’t going to spend months building this, only for it to be missing key features.

Second, change nothing. Equals was going to look and feel exactly like the spreadsheets you already know how to use.

Third, win with a single large bet. Our v1 had a single bet – data connections. We were pretty confident in this bet, but if we were wrong, the situation would be salvageable.

Outliers

Every startup success is an outlier. The best we can do in making things more repeatable is to squint and find what few patterns do exist. With the overwhelming amount of advice skewed towards MVP-driven startups, you might conclude that there isn’t a pattern here. That every “full build” is unique.

Yet, Tesla built the whole car. It’d be pretty hard to adopt electric propulsion otherwise. They didn’t rethink car interiors or exteriors. It’s a car. But it’s electric.

Peloton built the whole bike. They didn’t rethink bikes or group classes. They just brought the SoulCycle experience into the home.

Figma built the whole editor. Even today, the experience of designing in Sketch and in Figma is pretty damn similar. But Figma is collaborative-first, and it’s in the browser.

These are all Full Builds. They all built a large, complete foundation before being able to do the new thing. And – they all started with a single, large bet.