Startups Dilemma: Build vs Buy

Picture this: you're a startup founder (or CTO) with a vision of a product burning bright in your mind. You're ready to conquer your dreams, armed with nothing but your idea and a laptop. Well, hopefully with some VC money too. You hire your early engineers and embark on your entrepreneurial journey. Soon though, you and your engineering team are faced with a daunting dilemma: how do you best bring your vision to life?

When building out your product, you’ll need some foundational software that you can either build from scratch in-house or simply pay for an existing off-the-shelf solution and simply integrate it with your product. Having navigated this terrain myself at Frec, I've grappled with the nuances and complexities inherent in both approaches.

With building, you have the freedom to mold your product according to your exact specifications, crafting a minimal solution tailored to your unique needs. But let's not sugarcoat it: building software is no walk in the park. It requires grit, determination, and a healthy dose of caffeine. We often underestimate the effort required to build something.

I’ve seen countless posts on HackerNews claiming apps like Twitter, Uber, Snapchat, Pinterest, etc. are simply a CRUD app, and they can build it over a weekend. It’s typical for many engineers to underestimate the time and effort to build something. Yet, amidst the uncertainty, there's a sense of exhilaration when building something from scratch, I call it an engineer’s itch.

And sometimes, it actually takes a day or two to build out the solution that you need.

On the other hand, buying software off the shelf is like ordering takeout - it's quick, convenient, and satisfies your immediate cravings. With off-the-shelf solutions, you can hit the ground running, skipping the uncertain development process and diving straight into implementation. But understand that there is no free lunch, convenience comes at a cost.

Quite often, paid solutions are catered to a wide variety of use cases, and you might only care about a very small feature of the product. Yet, you have to pay for the entire package. Now that you have already paid for the package, you try to force-fit your other use cases into that solution. It's like trying to fit a square peg into a round hole—sometimes it works, but often, it leaves you scratching your head in frustration.

And finally, let’s not downplay the impact of vendor lock-in. Startups risk being shackled to a one-size-fits-all solution that stifles innovation and differentiation.

It’s quite evident that the decision to build or buy software solutions is the same as something you can use for any question: It depends. It’s not one-size-fits-all. It hinges on a myriad of factors, including budget constraints, time sensitivity, and strategic objectives.

Here is the framework we’ve used at Frec that has worked well for us.

• Find a balance between simplicity and speed, with simplicity taking priority.
• Cost is generally not a factor in most cases.
• Adding new infra overhead should be avoided as much as possible (aka simplicity).
• Be realistic, and don’t over-complicate a solution trying to solve for Google scale.

Let’s look at some real-life examples to see the above framework in action. Telemetry is mission-critical for any SaaS startup. It’s easy to fall into the trap and try to use OSS software like Prometheus and statsD to build something in-house. This would typically require you to self-host a service where this data can be published and viewed. And then you’d try to build monitoring over it.

This is called Application Performance Management (APM) and is a solved problem by many vendors. We decided to go ahead with Datadog since it was so easy to integrate with them using a client they provided and a free account (speed + simplicity). We could integrate with the Slack + notification system to manage on-call alerts.

Their agent setup on AWS took minimal config changes (no infra overhead) so the decision to purchase battle-tested software for something as critical as monitoring was a no-brainer.

With the integration, we got access to metrics to all our AWS infra, along with browser sessions on the front end.

Let’s consider another use case where we decided to build an in-house solution. Many SaaS startups require some kind of job framework to run periodic jobs. These jobs could have some cadence (daily, weekly, monthly) or might have dependency graphs (Run job C, only if jobs A and B are done). Once again, there are a lot of solutions that provide this as a self-hosted solution or as a cloud solution (e.g. temporal).

Based on the above framework, we decided to simply build this out since it took a couple of PostGres tables and an AWS lambda call to manage the entire framework.

We were already using AWS lambda and PostGres as our primary database, so it didn’t add any new infra. The solution has worked well for all our use cases, and we were even able to customize some specific use cases like stateful jobs running with a lag.

Whether forging ahead with a DIY approach or embracing off-the-shelf solutions, the journey of startups is defined by the ability to make decisions that make sense based on the company’s unique circumstances and the resilience to adapt in the face of uncertainty.