Should you buy a software solution to meet your business’s latest demand, or build your own? Every Software as a Service (SaaS) business asks this question at some stage of growth.
For some, the need is simple, like an automated email delivery system that can be quickly and easily developed. For others, it’s a more complex use case, requiring a dedicated team of developers to create and maintain.
Many years ago, I was part of a team at Protus, a fax marketing and broadcast service. We developed an internal solution to streamline our business: fax-to-email conversion. Every team member got a fax number tied to an email address, and any faxes sent to that number would show up in their email instead of getting printed out on a fax machine. This helped our business operate more effectively. We called the product VirtualFax, later known as MyFax.
As it turned out, there was a demand for VirtualFax outside of our business. It wound up becoming our biggest asset, outshining the marketing and broadcasting products.
VirtualFax was so successful that Protus was eventually acquired by J2 Global, better known as eFax. We had become one of eFax’s top competitors, all with what had been a relatively simple in-house built solution.
While there are clear benefits to building your own solutions, the option isn’t available to every business. Software development takes financial investment, resources, and in-house expertise.
Once those needs are met, there are also some important questions to ask before building, such as:
- Is this our development team’s core competency?
- Is there a clear path to ROI, or return on investment?
- Can we absorb resource coverage, time, and financials of the project if it winds up costing 50% more than expected?
If the answers to the above questions are “yes”, an organization’s leaders must then weigh multiple factors, such as the goals of the business, size of their team, revenue, and the problem’s complexity.
For larger businesses able to take on the challenge (and absorb the costs) of building, however, it is certainly worth consideration. Let’s compare options.
The argument for building: how in-house solutions benefit business
Building your own solution is a developer’s dream, allowing a business to fully customize the software to fit a business’s needs, and retaining complete control over the process and outcome. This means in-house builds are strongest when it comes to:
Customization.
When you build your own solution, the logic is tailor-written specifically to your business’s ecosystem. An in-house solution can be built with the specific use case in mind, without any extra features that won’t get used, and all the features that will.
Existing software may have customizable APIs and workflows, but it will never have the unique fingerprint of your business written into its DNA. A build means software can be as flashy and have as many capabilities as desired.
Compatibility.
Every business is unique, and thus has unique combinations of existing software and workflows which make up its ecosystem. An in-house solution will match up 100% with the processes and systems because that’s what you are building it for.
It’s very rare to find an off-the-shelf SaaS solution that can integrate with 100% of a business’s existing software. While you might find one that can integrate with, say 80%, there’s still the problem of figuring out how to deal with the other 20% and the fact that the logic of the solution is unchangeable.
Control.
It can be hard for some organizations to cede control of critical business information to off-the-shelf software. While it might be easy to hand off the aforementioned automated email system to someone outside of the business, many teams want to retain ownership of more sensitive and complex needs.
Building a solution means that steps can be taken to ensure that data remains in-house, and that any hiccups that occur are not the fault of a purchased solution.
An ideal in-house build is one that isn’t a drain on resources, is related to the business’s core competency, and provides clear ROI. Sometimes, you even get really lucky, like we did years ago while working at Protus.
Not all in-house software builds will be as successful as VirtualFax, but the point still stands: if the solution is something already in your business’s wheelhouse (in Protus’ case, fax), and if it isn’t a drain on resources with clear ROI (such as simplifying internal communications), then it can be a successful project.
Still, there are drawbacks to building which even large businesses may experience. Many of these are avoided by purchasing a solution instead.
The other side of the coin: benefits to buying
Even if a solution build is within a business’s core competency and provides a clear path to ROI, we have all experienced ‘scope creep’. What was intended to be a quick build may turn out to be different, larger, and/or more time consuming than expected, especially if the build is happening while the business is still growing.
“We don’t know what we don’t know” becomes really relevant here.
Today’s problem may evolve into a completely different one by next year. If a solution is still mid-build at that time, what does it mean for all the work completed thus far?
A great example of this happened during my time at Protus. In the early days, we built an internal provisioning/billing system. When we originally built this platform, we had no idea that the business would scale to 500,000 customers. We began building one internally with the business’s goal of 100,000 customers in mind.
Little did we know that we would have five times that number in just a few short years. It was an exciting time, except for the fact that the unexpected success rendered all of our work useless without constant attention.
We couldn’t keep up with the scaling, and suddenly what was meant to be a supporting product now required 8 people and significant infrastructure investment to keep up with growth.
In our situation, it probably would have been better for the business to buy; billing was outside of that team’s wheelhouse. There are also benefits to buying off-the-shelf B2B software we would have appreciated, such as:
- Known cost.
Most SaaS development teams know that if a build project is predicted to cost $1 million, you’d better be ready to spend $1.5 million to account for unexpected hurdles.
In a situation like our unpredicted growth at Protus, it’s hard to actually quantify just how much we wound up spending in hours worked and infrastructure invested as we constantly fought to keep up. A clear benefit to buying is predictability in cost and the ability to use that knowledge while setting long-term business goals.
- Time to market.
When you buy a solution, there’s no wait for a build, and no jittery process as the software undergoes patching to accommodate changes. After on-boarding and integration, the new software can be launched and implemented seamlessly, meaning there’s no wait to start reaping the benefits. It’s as close to immediate impact as you can get.
- Resource relief.
In addition to a quick launch, there’s no need to have team members dedicated to maintaining your in-house solution, and adjusting it if things change—like if your business suddenly begins to rapidly grow. An off-the-shelf solution can quickly scale to accommodate model changes or new products without burdening your resources.
The B2B SaaS provider is an expert in their field, so you can leave it to them. What’s more, these providers are likely to grow and add to their capabilities alongside your business over time. As they improve, you’ll improve.
These are all great benefits to buying, but of course, every unique business will also have to weigh their off-the-shelf options carefully. It is up to a business’s leadership to take time to figure out whether they are looking at the right solution for their needs.
Do what’s right for your business
Sometimes, buying is simply the way to go. Why build something that is outside your team’s area of expertise, or more expensive in the long run? Some projects are simply too complex to be worth it.
Ultimately, as with most business decisions, it will be up to the leaders to identify what’s best for their organization.
