Whenever we talk about technology — especially for SaaS companies whose bread and butter is software — the question is bound to arise: Do we go buy a product or do we build and manage it in house? 

For many questions about GTM systems and processes and organizational development, I’ll often say … it depends. Because the answer to so many of these questions really does depend: on your company stage, on your processes, on your team, on how many customers you have, on your existing tech stack, etc. 

But for the question of whether to build or buy a software solution, I have a straight answer: 

Buy. 

If the function isn’t a core capability of the product you’re offering, and there is a reputable solution out in the market, then you should buy. 

I’ve personally never met anyone who said that building a custom solution made them better off than buying a product off the shelf. 

My answer is simple for any SaaS company looking to accelerate their business. But let’s dig deeper into the real questions you should be asking when it comes to making the decision to build versus buy. 

‍What is your true competitive advantage?

I hear from a lot of companies that think that there’s something really unique or custom about what they’re doing. And that this “uniqueness” is part of their competitive advantage. This can often lead to a company thinking that they need to build a system to support what’s unique about how they do business. But I’d argue that, instead, it makes sense to standardize your process so it can be supported by a purpose-built solution. Your competitive advantage should be what you sell, the service you offer, the pain points you solve, how you treat your customers, and a whole host of other things — not just some quirks of your GTM process. 

It all comes down to ROI: Does your unique process lead to more revenue and more customers? If you don’t see positive outcomes, then what’s the value of this so-called unique process, and why are you so attached to it? 

‍Do you have internal expertise and resources? 

To build a system requires that you have dedicated engineering resources. It’s always going to be a challenge taking resources from your R&D group. Why would you waste internal development resources on something that’s not core to your business? Especially since there are lots of experienced companies whose sole focus is to build those products and keep them up-to-date. 

If you’re evaluating a vendor, just take a look at their org structure. Look at all the dedicated resources they have supporting the tool, from product managers to engineers to UX designers. Now compare that to your team … 

‍How — and who — will govern, audit, and maintain the software? 

When you build internally, the headaches increase when it comes to maintenance. Beyond the initial build, who’s going to maintain the infrastructure? And who’s going to make necessary updates when your process and products change and you need to adapt? The likelihood of your in-house system being properly maintained and having high up times is slim.

‍Are you thinking about scalability? 

In SaaS, many of us are powered by a strong bias for action. We like to jump in and try to figure out how to do something ourselves — often manually in Excel — before we try to solve for it with a new tool or technology. This makes a lot of sense because you need to have a deep understanding of what problem you’re solving for so that you can vet a solution. 

But when you go beyond that initial discovery phase and try to actually build out a tool, you only build for what you know right now; you don’t build to scale. You have no idea yet what you’ll need in six months or two years or further down the line. 

Whereas for a vendor, that’s their whole reason for being. The beauty of the cloud is that vendors can develop and deliver incremental features that you didn’t even know that you’d want to take advantage of, now and into the future.

‍Can you build to integrate with existing and future systems? 

It’s always a good idea to have tools that can speak to each other, that integrate well, and that give you a single source of truth for all the metrics you need. But integrations with an internally built system are very difficult — because you’ll need to custom-build those integrations. 

If you want something as simple as integrating with a document signing system, you’ll need to build for that. And then the next integration and the next as your needs change. 

Unless you have dedicated resources to ensure fidelity between your systems, you’re going to dig yourself into a corner. A tool that does everything end to end is the best solution — will your internally built system have that sort of seamless functionality? 

‍What’s the impact on time to market? 

Time to market can be one of the biggest pain points when you take the build route. 

Last year, I demoed our CPQ product for a founder of a small company. He’s technical, with a PhD in Computer Science. His initial reaction to the demo: I can build this in a week. And guess what … he did. But six months later when I reconnected with him, he had a very different perspective. He admitted that he had become a blocker during the quarter end. Sales were coming in with custom deals that the billing team couldn’t support, and now this technical founder was spending his valuable time working through the night to try to fix the system and keep up. One year later, he conceded that his situation wasn’t sustainable. He was ready to give up on his internally built system and buy a CPQ.  

While you’re trying to maintain and adapt a system to suit your business needs, you’re slowing down your business. 

While you’re waiting to find internal resources to build your system, you’re slowing down your business. 

When you build a tool and then outgrow it and have to rip it out to implement a purchased solution, you’re slowing down your business. 

‍What’s the total cost of ownership? 

I’ve seen this story play out over and over. And it always ends the same way. 

You may think that building is a better, less expensive, more efficient option than buying. But to determine the real cost of an internal build, you need to take into account the total cost — of tools, people, GTM impact, and on and on. When you factor in all the expenses over time, you wind up with a very different equation. 

So sure, you can build … but at what cost? The real question isn’t whether you can build, it’s why would you bother? 

Ready to buy a system that will help you solve your biggest quote-to-revenue challenges? Check out our CPQ buyer’s guide and subscription billing buyer’s guide.