In our previous posts, we’ve gone through all of the considerations you should explore when it comes to on-prem software delivery and management––from planning to maintenance––and now it’s time for the big decision. Who will get the rose: an outside vendor, or your internal team (and do they even want it?) Read on for the big reveal.
Just tuning in? Head back and read Part 3: Execution
Go farther back and read Part 2
Head all the way back and read Part 1
Congratulations! You’re about to reach your final decision: should you build or should you buy? You’ve gone through all of the factors that go into planning and executing the delivery and management of an on-prem solution. But there’s one more thing you need to consider, and it’s big. It requires you to think outside of your product and look at your business as a whole.
Let’s talk about resource allocation and smart spending. If the delivery experience is a core part of your product offering, then obviously a custom build makes sense. But if your core business is AI or machine learning, for example, then investing the time, money, and engineering resources into building a software delivery solution for multiple target environments––a feature that is not a part of your core business––could be a big risk.
If you want to achieve a growth rate that will make your business profitable and sustainable, then you’re going to need to delegate beyond your in-house team. Don’t fall into the “Humpty Dumpty” trap: according to McKinsey, “once growth is broken, it is impossible to put back together again.” Their data revealed that when software companies took a pause from growth––even when it was only temporary––they created less than a quarter of the value of companies that maintained their growth without pausing.
With this in mind, buying a commercial solution to deliver your application to customers could be a better choice. Letting your development team focus on creating core capabilities at higher velocity is a better return on engineering dollars and a smarter way to solidify long-term success.
That said, if you have the engineering overhead to spare, have at it. Build the exact solution you want and need; just make sure that there aren’t any economic consequences for doing so.
Every case is different, and all of these factors should be considered carefully before making a decision. There are situations where building a solution makes sense, either because you have the time, your requirements aren’t very complex, or if you simply don’t have enough customers to justify investing in an off-the-shelf solution.
But if you’re under time-to-market pressure, have limited resources, and need to focus your team on your product, then there is a lot to gain from working with a vendor. If this sounds like your situation, we built Replicated for you. Learn more about our modern on-prem solution that gives you the tools needed to scale, operationalize, deliver, and manage Kubernetes apps on any end-customer environment.
Let’s take a look at all of the factors side by side in this chart:
How did you do? Did you end up where you thought you would on the build vs buy question? It’s okay if your plans shifted throughout this process. As Winston Churchill once said, “To improve is to change; to be perfect is to change often.” Continuing to evolve your tools and processes to meet the moment is one of the best ways you can ensure that your business is a success.
We hope you found this blog series useful. Would you like to save an archive of it to reference or share with your team? Get the full series in our free eBook.