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:
Use cases / functionality (noting required vs. nice to have)
Deployment requirements
Security requirements
Service Level Agreements
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:
Functionality: How well do existing out-of-the-box solutions meet your needs?
Core competency: Is building this product part of our competitive advantage?
Time to market: Do you have an immediate need for the software, or do you have time to develop it in-house?
Cost and Opportunity: How much will the software cost to buy vs. build now and in steady state? What are we giving up?
Expertise: Do you possess the resources and expertise to make the software as good or better than current solutions?
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
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.