top of page
  • Writer's pictureGeoffrey Charles

To Build or Buy? Here's a framework.

Making the right choice of what to build internally or what to buy is hard but critical when developing products for customers. It can be the difference in costs, team sizes, time to market, and differentiation.

Today, there are a plethora of tools for businesses building software no matter the stage or the need - think AWS, Google Cloud, Heroku, Twilio, Salesforce, etc. Spinning up capabilities can now be done in no time, helping entrepreneurs focus on what they do best: innovate. Yet many startups still choose to build large solutions internally under the premise that they can do it better.

Whether you build vs. buy, start by defining the what you want.

Rushing into building could be tempting, but just like any product development process, you need to define what the product is before code is written. Writing the product requirements document is critical to align teams on what you are looking for in a solution. It should include, amongst other things:

  1. Use cases / functionality (noting required vs. nice to have)

  2. Deployment requirements

  3. Security requirements

  4. Service Level Agreements

  5. Data requirements

Once you have this document, anything you will build will have higher quality and impact. You can also use this document to send to vendors as an RFP.

Assess whether you want to build vs. buy using a common framework

Like every product management decision, the decision to build vs. buy should be anchored towards achieving maximum value for our customers and company. Here is one way to assess:

  1. Functionality: How well do existing out-of-the-box solutions meet your needs?

  2. Core competency: Is building this product part of our competitive advantage?

  3. Time to market: Do you have an immediate need for the software, or do you have time to develop it in-house?

  4. Cost and Opportunity: How much will the software cost to buy vs. build now and in steady state? What are we giving up?

  5. Expertise: Do you possess the resources and expertise to make the software as good or better than current solutions?

  6. Criticality: Does the product need to work out of the box or is there room to iterate?

1. Functionality

Pro Build

  • Very specific requirements that needs to be met

  • High customization and integration with system

  • Critical that data stays in our system

Pro Buy

  • Out of the box solutions exist

  • Solution is a commodity in the market

  • Solution is flexible - tooling exists to test and develop future features

  • Data can be put back into internal systems

  • Vendor system is compatible with the rest of your application

  • Vendor roadmap is aligned with yours

2. Core Competency

Pro Build

  • Building system part of our competitive advantage

  • Building system will set up to sell as a service

  • Building this system adds IP that is valued by investors

Pro Buy

  • Buy vs. build is the same outcome for our customers

  • Competitive differentiation does not depend on the solution, but how it is used

3. Time to Market

Pro Build

  • Time and resources to build this

  • Product is prioritized

  • Dedicated team

Pro Buy

  • Effort estimate large

  • Effort estimate uncertain due to uncertain requirements

  • Organization is engineering constrained

  • Product unlikely to be prioritized

4. Cost

Pro Build

  • Low effort estimate to build the system

  • Open source available to get most of the way there

  • Low cost to maintain the system

Pro Buy

  • Cost to sign contract + buy + configure + integrate + train < salary cost to build

  • Vendor easy to integrate with

  • Ongoing cost < salary cost to maintain

  • Opportunity cost of building is too high

5. Expertise

Pro Build

  • System does not require significant expertise to design OR

  • Expertise in house to build it (someone has already build it)

  • System does not need to be correct the first time & can iterate

  • Uncertainty in how the product will need to evolve in the future

Pro Buy

  • System required very significant expertise to build.

  • Limited expertise in house.

6. Criticality

Pro Build

  • System does not need to be correct the first time / can iterate

  • No need for full solution to go to market

  • Vendors are not mature / have not passed Vendor Risk Management

Pro Buy

  • System needs to work out of the box

  • System needs to have industry leading SLAs and Uptime

  • Vendor has demonstrated track record and sustainable business model

  • Using this vendor will help demonstrate competency to partners

  • Vendor has excellent customer support

Talk to vendors even if you decide to build - you will always learn something

Don't be blind to solutions that exist!

Set aside the ego of being better than enterprise SaaS and the pain of talking to sales reps - more information is always better. Talking to vendors is not hard when you know what you want. Spend time researching the space, talking to other companies about what they use, and defining a short list of potential solutions. Then send out your requirements in the form of an RFP (Request For Proposal) to these vendors. You will be surprised at how much work they will put in to show you their product.

Through demos and documentation, you will be able to get a much better sense of the complexity of the problem and identify new use cases that you may not have thought of, but actually will need in the near future or could use today. At the very least, these demos will help you improve your own specifications and the product you were going to build internally. More often than not, you will reconsider your assessment of how easy it is to build internally or how terrible existing solutions are, and may come to change your mind.

Build abstractions so that you can change your decision over time

Things change. Companies grow. Needs evolve. Vendors go out of business. New vendors show up with better capabilities. Maybe you found out the vendor selected is not the right one for you. That's ok! Your decision is not set in stone and in fact it should change over time. What you need to make sure of is that changing your decision is not excruciating for the rest of the company. To do so, make sure you have the right abstractions in front of the vendor so you can plug and play other solutions (even internally). This is more work up front, but will be tremendously important down the line.



bottom of page