Build vs. Buy: Why Startups Should Mostly Buy

When you're a hammer, everything looks like a nail. So PMs and CEOs are often the first to ask for custom tools. Let's explore the tradeoffs.

This post first appeared in Forbes.

I joined a startup in 2013 as its first marketing hire. We had fifteen employees and were earning less than $1 million in yearly revenue. WhenI left three years later, we’d grown to 100+ employees and 20 times the revenue. I’d grown the marketing team from just me to a team of 6, and sales from 0 to a team of 5.

One of the key lessons was seeing the tradeoffs first-hand when we chose to build vs. buy. And how that choice impacted the thing that mattered most: speed.

Many founders, especially technical founders, tend to favor building tools rather than buying them. “When you’re a hammer, everything looks like a nail.”

It’s important to resist that urge to build. The startup was an online coding bootcamp and had two teams: pre-sales Admissions reps and post-sale Learner Success managers.

Over the course of three years, these two teams took diverging paths with their tech stacks. This offers us two perfect petri dishes to examine the consequences of building your own tech versus buying from someone else.

Build

Our co-founder managed the post-sale team. As an engineer, and with product and eng reporting into him, he wanted to build tools and sought to automate low-leverage tasks.

• So, when our success managers needed to log customer data, he created a web form in the product to log the data.

• When the team needed a report on that data, he built a reporting dashboard exactly to their specifications.

• When we needed to change the status of a user from active to churned, that too would be functionality built into our app.

Through incremental additions like this over two years, we slowly built a homegrown education-CRM tool entirely our own.

This approach had strengths: It gave the team exactly what they needed. And since the data lived in the product itself, rather than in a parallel system, some tasks could be automated, such as welcome emails triggered directly from the app.

But this approach also had shortcomings: The platform was brittle.

• A small change to a web form, to add a field or handle an edge case, had to go through engineering

• There were edge cases that dramatically increased the engineering scope: like discovering our home-grown appointment booking tool needed to handle daylight savings time, or needing a system to adjust Success Manager <> Customer pairings.

Buy

I’d been starved of engineering support in every previous role, so I wanted to minimize eng dependencies. Looking at how our admissions team operated, I saw parallels to how B2B sales teams operated and decided that Salesforce, although not an ideal fit for an education business, might get us 80% of what we needed.

Implementing Salesforce was a herculean upfront challenge: It took an entire quarter to implement, not to mention $40K/yr in subscription fees. All of this -- the time, money and opportunity cost -- felt like a huge sacrifice at the time.

But once it was set up, it paid for itself in spades:

• When we needed to capture new data on sales calls, we created new fields in Salesforce in minutes -- no engineers necessary.

• When we needed data, we created new reports and data visualizations on the fly. And unlike the Success team, we could edit reports and add columns in minutes.

• We could automatically trigger customer emails. And unlike the Success team, we could change those emails on our own in minutes without engineering.

• We could automatically ingest sales calls, emails, and appointments, giving us much richer data on what the Admission team was doing.

• When our process evolved, we could edit lead statuses, opportunity stages, and required fields all on our own.

• Most importantly: while the Learner Success team might have a perfectly tailored tech stack, it took 3 years to get there. Our admissions team had 80% of what we would ever need by the end of that first quarter.

This is perhaps the biggest advantage of buying technology rather than building yourself: speed. Whether it’s Mark Zuckerberg’s directive to “move fast and break things” or Jeff Bezos’s decision framework of “one-way and two-way doors,” a common thread in startup wisdom is this: Your biggest advantage over large incumbents is speed.

Buying tools gave us speed.

One of the biggest hidden costs of building is productizing the recipe too early and then having to back-track.

As the Admissions team learned more about the ideal customer experience. Salesforce gave us the flexibility to modify our processes without engineering help. Had we built the perfect solution from the outset, we would have had to re-engineer it many times over the next two years as our process evolved. 

By far the biggest advantage of Salesforce was a feature set we didn't strongly consider when making a build-versus-buy decision: the robust reporting suite. The reporting functionality enabled us to answer almost any question on our own. This put the Admissions team light years ahead of the Learner Success team in terms of its ability to be data-driven. 

In summary, know that engineers will want to automate everything. Always remember what Paul Graham said: “Do things that don’t scale.”

So, buy flexible off-the-shelf parts whenever possible and iterate rapidly. Once you perfect the recipe and achieve some traction, only then does it make sense to build it in-house.

Being the first GTM hire is tough. The decisions you make on your technical stack will have consequences for years to come, leaving a mark that will outlast your tenure. But being there at the beginning may be the most fulfilling work of your career. Enjoy every moment of it.