How many times have you been stuck evaluating the pros and cons of building some kind of custom software versus buying an existing tool?
If you work in technology I guess it happened quite often.
Build vs buy is probably one of the biggest and oldest dilemmas in the software industry.
I know something about it. I’ve sat on both sides of the table.
For 13 years I’ve run a boutique agency focused on building custom solutions for enterprise companies.
Then for 6 years, I’ve been working on AdEspresso, a SaaS tool for Facebook advertising management.
In this role on one side, I was trying to convince potential customers to buy instead of building.
On the other side, while heading our internal development, I was constantly faced with the question: “Should we develop this feature or buy something ready from a third party vendor?”.
“Build vs Buy” decisions have been a constant headache across all my professional life.
On one side marketing team was pushing for the fastest go-to-market option, usually the “buy” side of the equation.
On the other side, the development team was usually pushing for using our internal resources to build. Especially when it came to interesting technologies to play with, like machine learning or cloud computing.
My actionable framework for Build vs Buy decisions
There are so many variables when it comes to building a homegrown solution versus buying from a software vendor that over the last 20 years I’ve come up with my very own framework to decide which way to go.
Since this is a recurring question when I advise early-stage startups, I’ve decided to share it with you, I hope it will be useful and help you avoid some very expensive mistakes I’ve done in the past.
Let’s get started. My Framework is based on 6 questions:
- How core is this?
- Does it provide a competitive advantage?
- What option preserves simplicity?
- What’s the fastest go-live way?
- Do I have the core competency to build this?
- What’s the cost of building and buying?
And here’s a quick recap you can download
How Core is this?
I don’t like spending software development time building stuff that is not close to my core business.
Overall, email marketing could be one of my main acquisition channels. That’s great. But it doesn’t mean I should build an email marketing solution internally.
In a Build vs Buy scenario, I tend to always make a buy decision for all the software components that are core business.
Another example is the server infrastructure.
Is it core for you to control your own servers and have a dedicated rack in a data center with your own servers?
If you are Netflix or Dropbox you could argue that yes… owning your own server infrastructure is part of your core business. If you are the average SaaS startup, it’s just a useless self-inflicted pain.
For most companies, it just way better to rely on a cloud platform to run their product.
Does it provide a competitive advantage?
Ok, let’s talk business now.
When you are investing in building custom software you usually want to be sure that it’s something that will provide your business a competitive advantage.
This step of the framework refines the previous one.
Let’s say you are running an e-commerce business. you could argue that the e-commerce platform it’s pretty core for you. Great!
But is it providing a competitive advantage over your competitors?
In most scenarios, it won’t.
I have direct experience here. In my agency times, one of our customers, with relatively low funding, decided to build a custom solution for his store.
He kept pumping money on the project, adding more and more features to make his store unique and feature-rich.
All those money were taken away from marketing and inventory. When he realized it, it was too late. He had a great store, with low traffic, a small mailing list, and not enough inventory diversity.
His customers appreciated all the features of the store. But what they really cared about were the products he was selling.
Had he picked a saas vendor like Shopify, he would have saved a lot of money to invest in marketing, getting more customers, and growing his business.
When you’re making a build vs buy decision always think: “Is this gonna give me a competitive advantage over my competitors?”
If it doesn’t, I always try to go for a Saas solution rather than building custom software.
If it does, then double down, make that project the most important of your team and improve it as much as you can to get an unfair advantage over your competitors.
What option preserves simplicity?
Simplicity is undervalued.
The leaner you can run your business the better it is. Every time you make a trade-off on simplicity, even on small things, remember that complexity sum up exponentially and the compounding effect can be really expensive in the long run.
Finding the easiest way to perform a task can have a great impact on productivity and business results.
A project requires a lot of integrations with other platforms, sometimes building a custom solution can be easier than buying a SaaS solution that doesn’t have all the integrations you need.
In AdEspresso we wanted everyone who signed up for a free trial to be automatically enrolled in a Webinar.
We started evaluating if we should build or buy.
The build way didn’t seem too complex. Our internal team had to write 50 lines of code to integrate with GoToWebinar.
The Buy way required us to use Zapier as a proxy between the signup form and the webinar platform.
Don’t get me wrong, I love Zapier, but in terms of simplicity of the system, writing 50 lines of code was way cleaner than adding another SaaS vendor to the stack.
Adding Zapier would have created:
- Another login to remember and for someone to own
- Another billing to renew when the credit card expired
- The risk of something critical to break if a token expired, or if a third party was accidentally down
- Another platform our team had to learn
It was just not worth it.
Here’s another example of how simplicity always wins.
In Breadcrumbs, we had to create a “request a demo” page. I wanted a very nice User Experience. We also wanted to pre-qualify users to redirect them to a webinar or a real 1-to-1 demo.
It quickly became a nightmare. We had to use:
- ConvertBox to do the survey
- Hubspot landing pages connected to Zoom for Webinars.
- Hubspot Meetings for 1-to-1 demo booking
To get the User experience I wanted we had to do way too many trade-offs on simplicity. Every tool had some pieces missing.
Convertbox had to send data to Hubspot, Hubspot had to send data to Zoom but didn’t support Zoom’s recurring meetings.
So every week we had to create a new Zoom webinar for the next week, change the id of the webinar in a Hubspot workflow, and so on.
The result: 40% of the time we forgot about one of these steps and screwed up the webinar.
Given the volumes were still fairly low, we removed all the tools, and forwarded everyone to the Hubspot meetings page to book the meeting.
We embraced simplicity over a complex setup and our demo bookings increased by 50%.
Simplicity should be your main driver. First in the build vs buy decision and then, if you decide to buy software to solve your needs, pick the SaaS vendor that will grant you the simplest setup, even if you need to do trade-offs in other areas.
What’s the fastest go-live way?
Strictly tied to simplicity in my decisional framework, there’s speed.
Timing is everything in business.
Facebook has posters everywhere in their offices to remember this, and it’s part of their culture.
Done is better than perfect
Move Fast and break things
Two odes to speed.
In my previous example about my struggles with Breadcrumbs’ “request a demo” page, I paid my mistakes twice:
- I added a lot of complexity for the whole team
- I lost business opportunities for weeks
See, the problem is not just the complexity.
The even bigger problem was that between implementing the complex solution and realizing it was not performing well in terms of conversions, we likely lost a lot of sales opportunities for a month.
Had I evaluated better my decision I would have realized that sending everyone to a simple Hubspot meetings page, was not just simpler, but also faster. I could have sent it live on the website in few hours rather than interconnecting multiple pieces of software for weeks.
My eCommerce customer experienced the same pain when we built his custom software to run his store.
Not only the money was better spent on marketing. He also delayed revenues by doing software development for 3 months instead of going live in few weeks with Shopify.
Whatever it’s building or buying, speed of deployment should be a key driver of your decision.
Do I have the core competency to build this?
Core competencies are another major things to consider when deciding if you want to build or buy.
Too often I’ve seen CEOs fascinated by the latest shiny objects ordering their team to go and build an AI solution into their product without taking into account if their internal team had the core competency to do so.
I’m not implying that if you don’t have internal resources for internal development you should always buy instead of building.
If all the previous steps of the framework leaned towards building, it might totally make sense to go and hire the resources needed for internal development.
But for sure, this is an important area to assess before making a final decision.
Do we have a data scientist? Is our team already skilled in this new programming language?
How long will it take our company to hire the resources needed before we can actually start building this software product?
Similar questions should arise also in the buy route. Buying from a solution provider doesn’t completely solve the core competency problem.
Once I’ve bought this product (or had someone build it for me) can my internal team take care of ongoing maintenance? Do I need to hire or train resources to use this product internally?
Before entering the final step of the framework where we’ll analyze the costs of both options, it’s important that you have a clear view of what your team can do, and what resources need to be hired.
What’s the cost of building and buying?
It’s time to get to everyone’s favorite element of the equation: cost.
Unluckily for many companies, this is the only step of their decisional framework. What’s cheaper.
This is a dead wrong approach in so many ways.
First of all, being cheaper doesn’t make it better for your business. Should you could save some bucks in the short term, but you might be giving up a tremendous competitive advantage in the long term.
Next, deciding if you want to build a software solution or buy a SaaS platform is something that will drastically change how you handle your business and shape your organization, it can’t boil down to only the cost.
Finally and foremost, when it comes down to cost, rest assured that most of the time your estimations are gonna be wrong, especially on the build side, so it’s not the best indicator to take the right decision.
Ok, now let’s talk about the best way to calculate costs in a build vs buy scenario.
Let’s start with the cost of building. The deadly sin of most companies is calculating the cost to build a software solution like this:
The output of this formula is light-years away from the real cost of building software in-house. Even further away if we’re talking about enterprise software.
OneSignal has come up with a great formula that I adopt in most of my projects. Here it is:
Let’s go through it.
Initial Build Time is basically the output of the simplified formula we saw before. What’s the cost of the development team for the time estimated for the project.
My only advice here is to always calculate cost assuming that the project will take more time than estimated.
How much extra time should you consider? It really depends on a bunch of factors:
- How good is your team (be honest)
- How long have they worked together
- How much they really understand what they’re building
- Are new technologies involved?
Usually assuming your internal team composition is pretty stable, over time their estimations will become more and more reliable and you’ll have to account for smaller delays.
Let me give you a real-world example. When we started building AdEspresso, even tho’ we had a great team, they were all recently hired, had not worked together a lot, and had a low understanding of the domain. They didn’t really understand how Facebook Ads worked.
The first few projects we built were a nightmare. Their estimations were off by as much as 100%.
They tried new technologies which created problems they were not able to foresee, communication within the team was not yet great. The product manager didn’t know the strength and weaknesses of each developer to optimize task allocation. Questions about every detail arose daily because of their low understanding of the domain.
For every new project we built, the team became more effective and their estimations became more accurate. We also put in place processes to track miscalculations so at every new iteration they could learn from what went wrong in the previous process and, as an example, allocate 10% of the time to chaos (unexpected problems).
Hosting costs are usually a bit easier to calculate but can add up fairly quickly. If the product you’re planning to build internally involves big data, the cost can grow exponentially quickly and soon add extra complexity for scaling.
Cost to maintain is usually the big hidden cost everyone in software development underestimates.
Building a custom solution is not like baking bread. Once your software is built it will need ongoing maintenance just like a car.
Machine learning models will need to be optimized or re-trained, technical debt will need to be paid off sooner or later, security patches will need to be applied, bugs will need to be squashed, and so on.
Depending on how complex is the custom software solution you are building, take the monthly cost to build the first version and allocate 5 to 20% of it every month for ongoing maintenance.
The range really depends on the kind of product you are building. For products with few integrations with other systems, you can expect a higher maintenance cost in the first few months that will gradually wind down as most of the bugs are fixed.
For products with a high level of integration with other platforms, the maintenance cost could actually go up. When we built AdEspresso, as Facebook became more aggressive in releasing new features we had to support and new versions of their APIs, the maintenance cost kept going up over time.
This is usually accounted for in the “Cost of Updating for Every Software Update“. Every integration you build in your product will require extra development when it’s updated.
It’s a best practice to always look back at how often a platform you are integrating has historically updated its APIs. The younger the platform the more frequent are the updates as a rule of thumb.
Cost of Adding Features… no v. 1.0 is perfect. Once your homegrown solution will get in the hands of users, the product manager’s inbox will be flooded with feedbacks and new functionality requests.
On one side this is the upside of building your custom solution, you have way higher control over customization. On the other side, it has a cost to keep your App always up to date with its users’ requests.
The average cost of a data breach for companies worldwide in 2020 has been $3.86m, a figure that keeps increasing every year. Building and Maintaining Security is not the place where you want to save money, especially if your project is gonna handle personal data.
Getting hacked is not among the hidden costs you wanna sustain.
This means dedicated resources, employee training, data handling best practices, and much more.
While this cost is usually spread across all your organization, the projects you add to the mix the more your cost to keep them secure will increase.
Finally, let’s come to the most overlooked cost element. Opportunity cost.
This is often overlooked because it’s not a direct cost you’ll have to pay someone. It’s another of those hidden costs you won’t realize until it’s too late.
Opportunity costs represent the potential benefits a business misses out on when choosing one alternative over another.
Whatever you are building, you’re making a trade-off. You’re choosing to allocate money and internal resources on a project instead of another one.
At some point in its life, Netflix for sure wondered whatever it should build its own server infrastructure vs. using AWS.
Building its own infrastructure would have likely cost a lot of money upfront. Yet, likely, at its current scale it could bring cost savings compared to relying on Amazon.
But the question is, what’s gonna grow the business the most, owning the data centers or investing those hundreds of millions of dollars in creating great content?
Given that Netflix is still hosted on AWS, I guess they correctly calculated the opportunity cost and decided it was wiser to invest in something that would create a stronger competitive advantage: great content.
Always ask yourself, what else could I do with these resources that could grow my business faster?
Calculating the costs of buying
Calculating how much you’ll spend if you decide to buy a packaged solution is usually easier. But not as easy as most people think.
Of course, every software provider can give you an accurate quote. That’s not the final cost.
When buying software always estimate these extra costs:
- Migration from existing solution if one already exists
- Onboarding cost. Most software nowadays requires a setup, integration with other systems, etc.
- Maintenance cost if you have to connect with the saas platform through APIs that will need to be updated every now and then.
- Offboarding cost. Sooner or later you might decide to leave that platform. How much will it cost you to migrate?
Back in the AdEspresso times, Hubspot had become a huge cost for us given the size of our contact list.
There were cheaper solutions around… we never switched. You know why?
First of all, because we loved Hubspot and decided it was worth the cost.
But even if wanted to switch, the cost of migrating all our integrations with Hubspot to another product would have outpaced any cost-saving.
Finally adopting a Saas solution over a custom-built one, comes at the expense of customization. You should try to give a monetary value to the loss of those custom features your team really wanted. (Hint: they’ll usually overestimate this cost).
Build vs Buy: What’s the right choice?
As you should have guessed by now, there’s no one-size-fits-all answer.
Nowadays I try to make a buy decision for everything that is not core and doesn’t add any real differentiation over our competitors.
In-App Notifications? There’s Magicbell.
Error management? There’s Rollbar.
Meetings booking? There’s Calendly.
All these tools solve critical problems for our company. And while they’d be relatively easy to build internally, they would not add any competitive advantage to our business. The opportunity cost is just too high.
On the other side of the Build vs Buy equation, everything that is related to our core product and value proposition, I am a strong advocate for building it internally.
I want to control the ins and outs of our product. Be able to customize it as much as we can to provide a magic UX to our customers. And I want my team to be able to react fast to any shift in the market.
I hope this framework will help you navigate the Build vs buy dilemma as much as it helps me at least on a monthly basis.
Would love to hear your thoughts and suggestions in the comments below.
I’ll close this post with a great quote Peter Drucker wrote in 1963 in his article “Managing for business effectiveness“:
There is surely nothing quite so useless as doing with great efficiency what should not be done at all.Peter