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.

28 February, 2022

Subscribe for updates

Subscribe for weekly advice covering product strategy, development operations, building teams and more.

Privacy and terms

I care about privacy as much as you do. I will only use your email address to send you this newsletter or to reach out to you directly, and you can unsubscribe at any time. I will not share, sell, or rent your email address to any third party, though I do store it the software I use to dispatch emails.

The information provided on this blog is for informational purposes only and should not be considered investment advice. The content on this blog is not a substitute for professional financial advice. The views and opinions expressed on this blog are solely those of the author and do not necessarily reflect the views of other organizations. The author makes no representations as to the accuracy, completeness, currentness, suitability, or validity of any information on this blog and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its use. The author may hold positions in the companies or products discussed on this blog. Always conduct your own research and consult a financial advisor before making any investment decisions.