I am amazed at how many conversations I’m having with companies wanting to rebuild software over the past 18 months. Not the typical rebuild akin to "We built this a few years ago and it needs a complete redo;" those are becoming few and far between. Complete rebuilds are relatively straightforward to dissuade from spending a lot of cash by focusing on how to modernize legacy applications. Although it’s possible complete rebuilds are needed from time to time, such a solution is rare and my colleague Brad Ediger is particularly vocal about the value of legacy code.
What’s more intriguing is how many companies are seeking to rebuild the SaaS products they've grown increasingly reliant on to sustain their operations — the products of their vendors.
Where SaaS Solutions Fall Short
Many companies rely on specialized solutions to manage mission-critical context or even core aspects of their operations. Initially developed as custom internal solutions for some other company, these products were fine-tuned for internal business goals and operational needs, then morphed into SaaS offerings for customers, often to recoup the significant investment in custom software. Although these solutions fulfill around 80% of immediate new customer needs, the remaining 20% often necessitates process or system workarounds and manual effort. Despite hefty fees and lengthy commitments, the functionality leaves much to be desired.
The crux of the issue lies in the SaaS providers' proficiency in service provision but their difficulty in transitioning into software product companies. They often fail to heed customer feedback, iterate, or rectify shortcomings beyond the initial development phase. Instead, they hastily implement quick-fix enhancements and rely on past accomplishments or exclusive features. This is partially because their roadmap is pre-set with an internal need to invest in new features that aren’t used internally and exceed the revenue from a few additional customers.
This approach invariably results in high per-seat fees and a disconnect between promised features and user utilization. Dissatisfied customers, facing looming contract renewals and fee hikes, often contemplate alternatives like in-house development and support. It also often means that customers are asked to foot the bill for new feature development. With that, the cycle continues.
The Mindset Shift From Service to Product
However, amidst this seemingly endless cycle of big spend, success stories such as Slack stand out as beacons of hope. Slack's transformation from a failed gaming endeavor to a disruptive communication tool underscores the importance of a product-centric mindset and customer value proposition. It also underscores a level of investment required for success. Killing the original mission to focus on Slack was a complete organizational pivot; one many companies are not willing to undertake.
When companies are thinking about rebuilding the software they get from vendors, they need to ask themselves some important questions:
Should we try to copy what our vendor made in-house?
What problems could we run into if we try to turn our internal tools into products we sell?
How do we balance building our own solutions versus buying from others so that it makes sense for our business?
These aren’t simple questions, but they’re worth digging into. Let’s take a closer look.
To Build or Not to Build?
Yet, the question persists — should companies embark on replicating their vendors' offerings? The answer lies in a strategic reassessment of your business needs and organizational workflows in order to steer away from blind replication toward a tailored solution that drives the business. Failing to do so will likely lead to a very expensive failure. Understanding and addressing operational inefficiencies through user feedback and iterative development are pivotal in achieving operational excellence. It’s easy to replicate workarounds that have been in place for any length of time and forget that it was only a workaround in the first place.
A testament to this strategic approach is Grubhub's deliberation between enduring steep vendor fee hikes or embarking on a ground-up rebuild. Opting for the latter, the company embraced design-thinking and event-storming to reveal hidden efficiencies and surpass vendor limitations. Their system has become a competitive advantage in onboarding drivers and is now core to how they grow their delivery business.
Transitioning Internal Tools to SaaS Products: Potential Pitfalls Ahead?
Transitioning internal tools into SaaS offerings requires careful evaluation, considering the allure of recurring revenue against the burden of ongoing support and maintenance. Crucially, catering to external users demands a paradigm shift in support mechanisms and user engagement strategies, underscoring the importance of customer-centricity.
It doesn’t make sense to open a core system to your competitors no matter the revenue potential. We wouldn’t advise GrubHub to sell its ATS system and give away a part of its winning strategy. It also would be a major distraction from the core business and would not further customer’s priorities.
Can your offering achieve customer goals — both roadmap direction and SLAs — while offering a reasonable price point? If not, you could put yourself in the same spot as your vendor, having to increase costs while the system requires workarounds and potentially doesn’t match the customers’ use cases.
How to Balance Build Versus Buy?
Considerations for rebuilding a vendor’s offering go beyond mere technical execution. The key lies in striking the right balance between four areas: innovation, customer satisfaction, operational excellence, and the total cost of ownership.
1. Innovation
If you’re deciding whether to build or buy, you need to think about how well your business can come up with new ideas and set itself apart. Building your own solutions in-house gives you more control over the development process and lets you create unique features tailored to your specific needs. However, this approach takes a lot of resources and expertise. On the flip side, buying ready-made solutions can give you access to the latest technology and features, but it might limit you in terms of customization that make you stand out from the competition.
2. Customer Satisfaction
At the end of the day, any software solution needs to meet the needs of the people using it. When you’re deciding between building and buying, you have to think about how each choice will affect the user experience. Building your own solutions gives you more control over how things look and work, so you can create an intuitive experience. But, you need to really understand what your users need and want. Buying ready-made solutions can give you a user experience that’s been proven to work, but it may not completely align with your company’s unique requirements or branding.
3. Operational Excellence
Choosing between building and buying software solutions can have a major impact on how effectively your business runs. Developing solutions in-house lets you create things that work seamlessly with your existing systems and processes, which can streamline workflows and cut down on manual work. However, it takes a lot of resources to develop and maintain. Buying ready-made solutions can be faster to implement and give you access to best practices, but you might have to change some of your processes or find workarounds to make them fit your unique needs.
4. Total Cost of Ownership
Lastly, considering the financial side of the choice to build versus buy is a crucial and careful step in this process. Building your own solutions in-house requires a big upfront investment in development resources, infrastructure, and ongoing maintenance. But this approach can save you money in the long run by getting rid of recurring license fees and giving you more control over future improvements. Buying ready-made solutions can have a lower upfront cost and predictable ongoing expenses, but it might end up costing more in the long run because of vendor lock-in and limited negotiating power.
As companies navigate this landscape, the emphasis should be on developing a deep understanding of their unique operational needs and leveraging technology not as a shortcut to industry competition but as a strategic tool for crafting bespoke solutions that propel them forward.
Breaking Free from Vendor Software Limitations
The success stories of companies such as Slack and Grubhub underscore the importance of a product-centric approach and the value of listening to user feedback to drive continuous improvement. Ultimately, the decision to build or buy should not be taken lightly, as it involves the potential for significant cost savings and efficiency gains, and the risk of diverting focus from core business objectives. By prioritizing customer-centricity and embracing iterative development, companies can avoid the pitfalls of vendor lock-in and create a competitive edge that is both sustainable and aligned with their long-term vision.
Interested in breaking free from vendor limitations and building software that effectively meets your needs? Let’s talk about how our strategic approach and technical expertise can help you navigate this buy versus build landscape and create solutions that drive your business forward.