To get a sense of how founders should approach the build or buy problem, we asked three brilliant technical founders—Charity Majors of Honeycomb.io, Dieter Shirley of Dapper Labs, and Ian Wong of Opendoor—how they approached that question when they first started out.
Lesson #1: You have limited ‘innovation tokens,’ spend them wisely
Before Charity Majors started working on Honeycomb.io’s platform, she had spent her entire career warning people not to build their own databases.
“Every software engineer dreams of writing a database when they grow up. I’d tell them: ‘Just don’t do it.’”
But when she and her cofounder started looking for a database they could rely on, they quickly realized nothing quite fit their needs. If they were going to build something that looked and felt unlike any other product out there, they’d have to build their own from scratch.
“At the same time, when you’ve taken venture money, VCs expect you to be out there proving your product from day one and getting it in front of customers,” points out Majors.
Building their own database would mean that they wouldn’t be able to start doing this until a year and a half in, which created tension with their investors.
“It almost killed us,” she admits. “I managed to antagonize and alienate our first couple generations of investors.”
Although Honeycomb was eventually able to find investors that were more patient, Majors says it all “easily could have gone the other way.”
When thinking about the buy vs. build problem today, Majors refers back to a blog post by software engineer Dan McKinley.
“If you’re a startup, you have two or three ‘innovation tokens,’ so spend them wisely. You can’t innovate on everything. You have to use the tried and true as much as possible so the things that you build yourself can become real core differentiators.”
“We chose to make our storage engine our one big innovation token, and we tried to go very ‘middle of the stream’ for everything else.”
To learn more, check out our full interview with Majors here.
Lesson #2: Calculate the risks, then balance them
Dieter Shirley of Dapper Labs is intimately familiar with the process of building brand new.
He recalls how on time he and his team used Swift to build an iOS application back when Swift was still new and unfamiliar, simply as a way to keep the engineering team interested and engaged in the project.
“Another example is Flow. We had a team that had a lot of grounding in Golang but the received wisdom was that something like Rust is much more robust and performant than Go. And the question that came up was: should we build the Flow blockchain in Go or Rust?”
Shirley settled on Rust, deciding that if it was the wrong choice, they’d learn it was before launching.
“Whereas if Go was the wrong choice, we would find out after we launched. It seemed to me that it’s far better to launch, and so was the uneven risk.”
Shirley says that balancing and comparing risks in this way is ultimately how he approaches the buy or build tradeoff. In the case of the iOS app, balancing the risk of potential engineer boredom, and in the case of Swift, balancing the technical risk of Go and Rust.
“Minimizing when it comes to a tech choice of something new versus something that the team really understood well was the right choice there. I think it’s really about identifying the biggest risks.”
Read more in our interview with Shirley here.
Lesson #3: Only build if it’s your ‘secret sauce’
For Opendoor’s Ian Wong, building or buying ultimately comes down to determining which problem you want to solve and what kind of competitive advantage a startup wants to develop.
“You have to ask yourself, how unique is this problem, and how important is it to solve the problem well?”
Wong says the key is to identify what exactly it is that is going to give a startup some kind of unique edge, and to then devote most of the company’s resources to developing that edge.
“For us there are areas where we’ve got to push a boundary, like our pricing and data applications. Pricing is an area that makes or breaks a company. So we’re really willing to adopt and build new technology.”
On the other hand, Wong points out that there are plenty of business problems that don’t require a technical ‘secret sauce’ to fix. Using off the shelf tools and focusing on managing a complicated business problem can be enough of a challenge, and devoting resources to building new tools can be more of a distraction than anything.
“For instance, at Opendoor we are orchestrating thousands if not tens of thousands of workers to inspect the home, talk to our customers, maintain the home, make sure the home is ready for resale, service the buyer and all that.”
“In that sense, you have a lot of technology risks, but really the key risk is how to model [those tasks] well and manage complexity.”
Wong says that in that situation, relying on new technology that team members have an incomplete understanding of can create more problems than it solves.
“Again, it really depends on the type of problem that you’re trying to solve.”
Read more about Wong’s experience in our full interview here.
###