September 03, 2021
'Build or buy?' may be the most common question I've been asked over the years. Often, we can clearly identify the business need and even what the technology would look like to address it. The question then becomes "Do we build this ourselves-- in-house or outsourced (the subject of another post), or do we buy some off-the-shelf (OTS)/SaaS solution?" The answer is never clear, but here are five things I like to consider when making that recommendation.
Do you have requirements that an off-the-shelf solution can't accommodate? It may be tempting to wave your hands and say "we'll customize it later" or "we don't really need that special function" but take the time to really talk to your users and subject matter experts to assess that. It's often that "special feature" that represents some competitive advantage. Just as likely, it may be a "we've always done it that way" feature that can be accomplished in another way. Take the time to find out. There's nothing more frustrating than to find out later that your purchased solution does 90% of what you need but not the important 10%.
What's it going to take to actually integrate your purchased solution into your existing process and infrastructure? Does your solution need to talk to your ERP? Does the OTS solution have an adapter? Does it integrate at the level that you need (e.g., a batch summary dump of data vs. transactional API)? In different situations, you may have a web of integration points or none. Identify all of the sources and consumers that you need to integrate and do the exercise to plan each one. The ability of a product to integrate (or not) with other systems can save you a fortune or doom the project to failure.
Do you have the resources to maintain either the purchased solution or the custom-built solution? Again, this applies to both scenarios. In my experience, the classic example is Sharepoint. Companies want a repository for their data. They want to collaborate. No one ever got fired for buying Microsoft, right? But Sharepoint is a platform. That platform requires care and feeding, and most companies underestimate the importance of that administration function. So, they buy Sharepoint, put up a few documents, and before too long, no one can find anything or access what they need.
The same goes for complex, custom-build solutions. They're often amazing at first-- perfect fits for the job at hand. But then they slow down. Something didn't get an index, or the infrastructure changed and broke the integrations. Particularly when outsourced development is used, this can lead to an expensive return engagement to fix an emergency or even total abandonment of the platform.
When building a solution, it often appears to be a less costly option because the costs of the purchased solution are up-front and obvious, whereas the costs of the custom solution are, at best, estimates and often don't include follow-on costs (see 'Maintenance'). Or the custom-built solution seems expensive compared to the month-to-month cost of the SaaS option. In that case, we tend to underestimate how long we'll use the product (probably many years), how many people will want to use it (more than we thought), and the desirability of certain features (you want single-sign-on? Oh, that's the Enterpri$e edition.)
Do you need a solution now? Can you wait for developers to build it? Is there a critical needed feature of a potential purchase that's "on the roadmap"? Roadmap features may never show up. Your developers may get called off on critical product or client work. Assess your timeline and the risks of it not being met. Be realistic and build in plenty of slack. There's a reason you hear experienced project managers say: "Figure out how long it'll take and double that. Then double that."
While there are plenty of other considerations (e.g., the viability of the partner or the tech being considered), these are five that can make or a break a decision when really examined up-front. Take the time to do so. Each may influence the others. Prioritize items as "showstopper", "important", and "nice to have". Avoid the temptation to let a good price or an easy answer cause you to accept a solution that doesn't truly meet your needs or to fool yourself into thinking that you'll choose the easy answer now and really solve the problem later. Most often, the stop-gap solution sticks around for years-- hobbling efficiency and causing frustration and errors.
Need help with the process of evaluating or building a solution? Drop me a line