The Modern Leader
If you’ve worked in engineering for any reasonable amount of time, there’s a very strong chance you’ve encountered a build vs. buy scenario. For the lucky or for those who have no idea what I’m talking about, the question is straightforward: do we build this software in-house, or do we use a third party software product? The answer, however, is anything but straightforward.
We all encounter this scenario several times in our career, and every time this scenario needs to be considered with care. This week I’m presenting my rough framework for discussing build vs. buy with your team and stakeholders. As in, you don’t make this decision on your own. As in, PLEASE involve everyone necessary to make a decision.
1. Assess needs and goals.
Define your specific requirements, long-term goals, and constraints. The problem statement needs to be super clear; there shouldn’t be any confusion around what you’re trying to accomplish and why. Use this as an opportunity to evaluate if existing solutions meet most of your needs. You should be especially careful here to leave any bias out of your assessment. I’ve seen on several occasions a clear bias for a particular solution.
Determine the level of customization needed. Can an off-the-shelf solution be tailored to your needs, or will attempting to customize an off-the-shelf solution result in greater debt than it would to just build it from the ground up?
Also evaluate scalability - how well does the solution accommodate future growth? Outside of the cost implications outlined below, how might this solution scale from 500 to 5,000 to 50,000 to 500,000 customers using it?
Don’t think just in the short-term either; consider the future roadmap of the software and how updates, enhancements, and support would play into this in the long run.
Lastly, assess the urgency of deployment and how quickly you need the solution. Obviously buying an existing solution will often result in an earlier delivery time, but at what cost? There’s always the option to buy now to build later, so consider a short- and long-term delivery timeline here.
2. Run a cost-benefit analysis.
Calculate the total cost of ownership for both options: initial purchase/build costs, maintenance, support, and scalability. If you were to build, how many engineers are required to architect and develop the solution? How about to support it thereafter? Beyond the cost and time of engineers, what about hosting and server costs?
If buying, how much is the solution now, and how much will the solution be down the road? You can often swing a discount in your first year, but what about the following years? How much do you expect the cost to increase as usage scales? Consider potential savings in time, resources, and future updates as well. I also tend to think about who built the software we’re considering. What’s the stability status of their company? Are they an early-stage startup or more mature? I take serious consideration towards using a product that’s still in its infancy, especially if it’s going to be supporting a core function of our own software.
3. Assess the technical experience of your team.
This one also falls in line with overall costs and timeline. Needing to pick up a new skill means a longer delivery timeline to build and support, especially if it’s a large enough feature requiring the involvement of multiple engineers.
There’s also a learning curve for adopting an existing technology. If building on top of someone else’s solution, what is the expected ramp time to feel fully comfortable supporting the technology?
This is a simple framework, but these questions cover a lot of ground. I always encourage my team when evaluating potential software solutions to dig and find several “buy” options to eliminate some bias and ensure proper research has been done. The engineer in charge of this then presents to the key stakeholders to discuss the pros and cons of each option, ultimately ending with a general conclusion on build vs. buy. These live review sessions are incredibly useful as you’ll get questions you weren’t thinking about.
I end this post with two final points:
- Don’t fall into the trap of “buy, then build” and never actually get around to building. Commit to a build date and make sure it remains on the calendar. It’s helpful when you’re signing a fixed contract for a service (e.g. 1 year) so you can use that deadline minus 1 month for some wiggle room as your build launch date.
- If you don’t agree with the decision made, disagree and commit. If you build and you were urging to buy and it turns out buying was the better option, don’t say “I told you so” – it’s not beneficial. Just move on and move forward as a team.