Last month we talked through build vs. buy. Judging by the questions that followed, we have more to talk about! If you missed last month, click back to August before you read on as there are some premises covered there that we won’t revisit in this post. This month, we focus specifically on buy.
Let’s be upfront . . . buy means you don’t own the code and you can’t do whatever you want with it, so you need to be certain that what you get meets your needs. If there’s nothing in the market that fits the bill, you may genuinely need to develop a full product. If there are viable solutions yet there’s still internal pressure to build, here are some thought exercises to help navigate the discussion.
With a SaaS solution, you’re getting the benefit of massive intellectual property that exists today, will continue to be enhanced, and is purpose-built for your use case. I try to keep this blog free from product plugs, but for expediency’s sake, I’ll shamelessly use Claimatic as an example here. If you need a claims triage and assignment tool, you sign up with us and you’re online in 30-90 days. Everything that went into that experience took experts 10 years to build & fine tune, and we’re still constantly improving it. Do you have 10 years to do what someone else already does well? Is owning the code important enough to be late to market with the capability?
SaaS solutions allow you to experiment. Try it on for size, see in short order if it works for your company, and then keep it or kill it. You’ll expend one to three months in that exercise to get to a decent assessment vs. waiting DIY taking six months to a year (or more, depending on complexity) before you even have anything to begin testing. You could test four SaaS products in that time! Dovetailing into the trial run concept is SaaS’s most touted feature, the consumption-based, pay-as-you-go model. Compare the cost of trying a SaaS solution for three months and consuming it for nine months vs. one year with the high upfront cost of securing the necessary resources (see July’s blog for more on this).
There are hard dollar costs that you can quantify, and there are hidden costs that are a bit more challenging to express. In terms of opportunity cost, what will it take away from the business over the life of the project for your leadership, subject matter experts, business analysts, project managers, and compliance specialists to step away from driving the business and step into guiding an IT project? Do you want them engaged with IT for a couple of months on the front end in assessing vendors & evaluating an app, or do you want them engaged forever?
The second hidden cost is accrued risk that comes in the form of compliance and attrition. When you go DIY, your organization is forever on the hook for increasingly complex compliance requirements and annual audits. Any one mistake in that area can be extremely costly – think lawsuits and headlines. Finally, there’s attrition. The workforce is much more fluid than it once was, especially for tech workers. When you go DIY, you’re generally reliant on a small handful of people who fully understand the product. I’ve worked with very advanced, multi-billion-dollar companies who had all the appropriate documentation you could ever want, but when key staff departed, they were left with no one who really understood the care, feeding, and growth of business-critical applications. They went from innovating to keeping the lights on, and they incurred the new expense of finding qualified resources to engage in extended reverse engineering.
So, I’ll end where I started. Are there cases where DIY makes sense? Yes, but they are few. Why spend your precious time and resources re-creating the wheel when someone else already has a perfectly good wheel? You could instead be moving your business forward, and rest assured, your SaaS-ready competitors will be doing just that.
