It's 3AM. You finally were able to fall asleep, one headphone is listening to the soft rain-sounds playlist on Spotify, your head awkwardly positioned on the pillow.

ding! Must be in your dream, you think.
ding! No way this is happening, I'm not even on call this week!
ding! UGHHH, FINE!

You roll out of bed and see a Slack message from a coworker in timezone B, the daytime timezone. Production is down and they don't know why.

The three legged stool of a great product

Let's discuss the three required components of building, maintaining, and selling a great tech product.

A great product is like a three legged stool. A great stool is stylish and functional. A stable stool can support a ton of weight. And much like a three legged stool, without one leg, the whole thing comes crashing down.

The three legs:

1. Reliability
2. Flexibility
3. Marketability

When constructing our "stool", we have options to consider.

Some prefer to build their entire stool by hand. They enjoy the process of hosting their own servers, creating their own data layers, security protocols, and messaging buses. They want to interact with the 1s and 0s of every part of the stool.

And for a long time, this was the only way to build a stool. Every company would come to the stool convention with their homemade stools made of different woods, stools that are different heights, some stools with wide seats and some with small ones.

The late 2010's saw a surge in SaaS and PaaS companies. These companies offer APIs for commonly needed tech services, from hosting to searching to sending data to your end users. These tools cost $$, and in return they solve a part of your pipeline. This is equivalent to ordering really high quality, pre built materials for your stool at a premium.

But which is preferable?

Build vs buy: the arguments

In the first corner, weighing in at 6000lbs, we have PaaS!
In the second corner, weighing in at ~3lbs, we have DIY solutions!

The arguments in favor of an in-house solution: you get 100% control over the process and your costs look different on paper. Depending on your tech choices, you avoid vendor lock-in, and you’re not vulnerable to the customer service of another company. You manage all of your own releases, and get to decide when to update your stack.

The arguments in favor of a PaaS solution: the entire product is packaged and you interact through a simple API. You’re getting the latest and greatest workflow processes, from a company whose engineers are solely focused on solving that one problem. You get guaranteed uptime, and by decreasing your bus factor, you make your own product more resilient.

Let’s head back into our stool analogy and dive deeper into the factors of a build vs buy solution.

Game of uptime

In 2019, customers expect performant apps. The end user couldn't care less if your tech stack is running on the most advanced Kubernetes cluster, or on four potatoes in your attic.

“Premature optimization is the root of all evil.” - Donald Knuth

Sometimes, a member of your team will decide to implement a solution that feels good or has been buzzing in the Hacker News circles. Unfortunately, history has shown us that feels good technology !== stable, reliable solution.

It’s worth taking a moment to remember how the world was when everyone built their own tech stack. Today, we’re spoilt. The nature of the 24-hour-7-days-a-week product like YouTube or GitHub is that in order to provide value, they need to be up all the time. But just eight or ten years ago, it was common for websites to go offline for maintenance. Restaurants can close at night to change the lights and fix the table legs, online businesses no longer have that luxury (I mean, of course, we all know that online banking plays by different rules, though).

Uptime is critical because it shows your end users that you have a reliable product. You want solutions that are battle tested. If you get a spike of traffic from Brazil at 1am, will you be able to handle that?

More importantly, will you be able to handle that with the load balancer you built during that one sprint three months ago?

What is your purpose?

You want to create something new. Something exciting that your target customer will want to use.

You create mock-ups of your features, and begin speccing out how long it will take to execute the project. The engineers, project managers, and designers all run to their separate corners and get to work on their piece. Everyone is excited and ideas are buzzing.

And it’s at this point that people get tempted to build everything from the ground up. "It's a cool challenge to build our own data layer from scratch!" or "I found this super cool new JS library that uses ES6! Let's use it in prod!"

Wait.

There is a major implicit cost in this. You are spending your own time reinventing the wheel instead of working on your product. And unfortunately, until that time machine is finally built, time is a non-refundable resource.

The faster your product hits the market, the better. Why? Because you’ll be able to focus on what the market wants earlier, and you’ll be more likely to get first mover advantage! Faster to market means less money spent, and the ability to have a mature product (read: more than a demo and a slide deck of what your product WILL do once you figure out your payment layer algorithms) to show off sooner. A faster product has the major advantage of being more flexible as well.

As Reid Hoffman (founder of LinkedIn) once said:

"If you're not embarrassed by the first version of your product, you've launched too late."

You want to build a marketable product. A product that has a specific use case and can be sold. You shouldn't need to learn how to chop down trees if you're trying to build a stool.

YOUR product

What do you want to be remembered for? Do you want to be known for how innovative your product is or for that one weird trick you used when setting up your Postgres cluster?

When you are with your team and you're discussing a go-to-market plan, think hard about where you want to focus your resources. If you have a peculiar use case that requires an infrastructure powered by quantum computing, say, then it may be worth building your product from the ground up.

However, if you are trying to compete with larger competitors that are already on the market, then you owe it your product to build on the shoulders of giants.

Simply put, PaaS platforms, APIs, and other products exist to allow you to spend more time focusing on delivering the value that only you can deliver. And when everything’s in production, they get to handle the 3AM infrastructure calls while you sleep soundly, ready to tackle the next day’s business challenges.

Conclusion

Whether you’re building a boot-strapped start-up or you’re in a team at a multi-billion dollar corporation, you have limited hours in the week and limited budget.

Build vs buy is probably the most impactful decision you’re going to make in the early days of a project and you need to make it for every technology in your stack. It’s the difference between spending those limited hours reinventing the wheel or delivering something brand new to the world.

While learning Kubernetes sounds compelling, running your own infrastructure is a distraction for the majority of projects.

Instead, PaaS platforms like Heroku give you the opportunity to get to market faster and simplify both your development and your ops.

So, build vs buy is often a simple choice to make. If it won’t make a difference to the end user, then you should always choose “buy”.

Stools photo by Charles
Bus photo by David Henderson