To build or to buy (or partner): a guide for startups

Startup leaders are constantly facing decisions of whether they should build something themselves, or buy an out-of-the-box third-party solution. I believe startups should be biased against building anything inessential that doesn’t pose a legitimate opportunity to create a competitive advantage. In other words: only do what you’re positioned to do better than anyone else.

For engineering leaders, this question is most often regarding behind-the-scenes tooling or dependencies. It could be something as simple as whether it is ok to depend on a third-party open source library for some simple functionality, or it could be something more fundamental like whether it is better to use a third-party SaaS product for something like feature flags, as opposed to building something in-house.

For product leaders, this question can also pertain to product features, though instead of buy, the alternative to build is more likely to partner (i.e., integrate/collaborate with a third-party who already solves this problem). This is because most products exist within a broader ecosystem, so many of the problems your customers need solutions for, have already been solved by others. For example, when building an ecommerce platform that is differentiated by providing a fantastic shopping cart experience, you might choose to partner with another product that specialises in marketplace integrations rather than build them all out yourself. This is beneficial to both companies, who can remain focused on their areas of differentiation, and are now stronger together.

In either case, the guiding principle needs to be opportunity cost above all else. Startups succeed by solving one big problem the best way possible for their market, and any work that is not directly related to solving that problem should be highly scrutinised. Where possible, work that distracts you from obsessively proving the core hypothesis of your business should be avoided. Building your own solution for something (e.g., feature flags) might seem easy enough and could also be an opportunity to save ongoing costs, but this measure of return on investment does not consider the cost of being distracted from your core mission as a product.

Whether it’s a piece of common technical infrastructure (e.g., feature flags, analytics, email delivery, or payments) or a tool to help your team to acquire and service customers (e.g., a product knowledge base, support hub, or marketing website), an out-of-the-box solution is most likely the best path. Sometimes, legitimate opportunities to differentiate a product through custom internal tooling will arise (e.g., some product categories are difficult to tackle because they are too expensive to provide customer support for, forcing businesses to differentiate their products through internal tooling and automation that makes support more efficient and might not be directly related to the product itself), but it’s best to be sure about these before distracting your team.

Solving product feature requests through partnerships with other SaaS providers can be a great way to reduce roadblocks for your sales team without committing product development resources towards problems that are only relevant to a subset of your market, allowing you to remain focused on building solutions that will be valued by the majority of your customers. Smart product teams will often integrate with a third party and reassess the desirability of an in-house solution down the track. Often, it is discovered that the third-party solution is more than adequate to keep customers happy, and teams can continue to focus elsewhere. Alternatively, teams might discover that there truly is a great opportunity here that should be explored more deeply.

Another way for product teams to respond to distracting requests that are pulling them away from their core focus is to prioritise the extensibility of their product, and rely on professional services partnerships to provide customisations where necessary. This approach is especially useful when the solution to a problem is not clear, and different approaches for different customers are likely to be required, though it usually only works for products that are targeting larger enterprises or developers. Typically, this means the product development team will build APIs to enable third parties to build the requested functionality and work with a third-party professional services company to build the feature for their customer. This approach keeps their core product narrow and focused, fosters a professional services ecosystem around their product, and removes roadblocks for future prospects who want to solve this problem in their own way.

The build or buy question is often difficult to answer, but it is made easier when product teams are focused on building towards greater differentiation, with an adequate level of scrutiny built into their prioritisation processes. By considering what you are delaying in order to build something you could otherwise outsource, you will form a better idea of the real cost of this work.