The 5Cs of the Build vs Buy Debate of SaaS Development

The debate behind build versus buy is a lively one in the world of SaaS product development, and although it can be discussed ad infinitum, we do need to sit back for a minute before we build a SaaS application and consider the following: 

What are the key reasons that drive a company to build vs. buy? Does the strategy work long term as well as short term? Have we accounted for the time, resources and infrastructure needed to reach our long term business goals? And are we motivated by emotional or rational factors that affect our decisions? 

Check out our 5C’s as they relate to the “build versus buy” SaaS development debate.

Levels of Customization

There is a (mis) conception in SaaS product development that when you build something that is tailor made to your business needs it will ultimately be better and more custom fitted to your company than anything you could buy.  This “dreamy” tailor made product has the unique fingerprint of your team and company built right into it. It’s a great feeling to build your own SaaS application. You can go as flashy as you want without being held back by product limitations and you can build features upon features that have as many capabilities as you desire. 

Imagine you’re getting married. Congratulations! It’s going to be a big day and you’re super excited. 

But wait! With your wedding day coming you have a million and one things you need to get done by then: order a hall, caterer, DJ, invitations, flowers and more. You want everything to be perfect and it’s never too early to think about your wedding suit. You have this really cool style you want to explore so either you can buy a suit off the shelf, or because you want something really unique, you can start to think about personally working on designing and tailoring the suit yourself. Are you a tailor? No of course not! But how hard can it be? Well, if you’re Versace then the answer is not hard at all. But if you are just you, then designing this suit on your own might not be the best allocation of time and resources considering all the other things you need to do in preparation for this once in a lifetime moment. 

Many of the key decision-makers in the global software technology firms actually believe in building because it lets them create a unique customer experience that differentiates them from their competitors while increasing engagement with customers, partners and employees. At the same time, a large portion also feel that unique might not always in fact be better. When building in-house, there is a desire to aim for perfectionism: pixel perfection allows you to consider every single detail down to the individual pixels (just like your suit: material, design, quality etc.) but you might lose focus on what you really want to achieve. 

This can especially prove to be challenging when you face a substantial growth period in your company both in terms of time, resources and funding. Balancing this out by focusing on developing the core aspects of your application, while keeping the 80:20 Pareto Principle for the non-core features in your app is one way to still differentiate yourself. Bottom line: try to consider your long term planning and the factors that are necessary to keep your team’s motivation up, to scale and to maintain your SaaS, whatever direction you decide to go in. 

Control over your product

Wanting to retain ownership over your sensitive and complex data and architecture is common. Data control is essential for some companies and with the need to govern and manage data, you might wonder whether building or buying your own data controls would be best. Control comes with a price, as you will need to take into consideration your time to market that an in-house solution inevitably will present. In order to rapidly scale you will find yourself allotting much of your company resources to the core product and customers while also requiring increased in-house maintenance.

And if you do choose to “lose” control, you need to ask yourself who you are relying on to help you manage your sensitive data? For your core data you want to maintain control, but outside of your core, maybe you can afford to lose control. 

Take a company like Stripe for example, an online payment processing gateway that handles all of your financial transactions, subscriptions and payment details. What if you decided to focus a large part of your development on figuring out how to receive payments from your customers while neglecting your true business features? The misappropriation of time and resources would cost you and your company greatly. 

So in the end, you aren’t really losing control since today there are solutions for container-based functionalities, such as dockers and microservices which allow you to gain control over what is happening within the essence of your business, without actually losing control of your core product. 

Returning for a second to your wedding suit, imagine you decided to hand over your design ideas and vision to an experienced tailor who could implement them for you? When you walk down the aisle, would anyone really know who sewed the lapels and cuffs of your suit? Ultimately, you want to shine, and shine you will, since you will have received the final product you were looking for even if not exactly how you had originally planned it. It’s all about focusing on what matters most. 

Compatibility and Implementation

Compliance, architecture and infrastructure, are all important parts to your software components and if you are buying a solution to manage them, you need to ensure that these elements meet the standards of your compliance and support all of the controls that you claim to be upholding and controlling within your organization. 

When you start to build your product you aim for a certain level of service and customer growth. And if you have chosen the right management tools for these critical parts of your SaaS, you will still be able to scale and maintain the growth you are aiming for, usually without a substantial investment in further infrastructure and team. Your users will also vary from marketers, to product managers to engineers, each looking for different features and actions and most likely with different levels of activity as well. Using software components that make your SaaS compatible with your needs and fits right in with your current action items and company goals is rule number one and it means understanding who it is you will be relying on for these services.  

Competency & 3rd party integration

It may be enough to look at your team and their core competency and to decide that building notification centers is just not as important as what we woke up to accomplish this morning. A solution you are building now may evolve by next year mid-development. Even if you are builders by nature, you will still prefer to focus on result oriented development while buying those features that are close to impossible to build yourself: authentication, reporting, task management, to the companies that make it their core focus. 

It really makes sense if you think about it. Only a century ago, it was an accepted practice to have the one suit you owned, custom made. The fact that today the industry has changed how we purchase clothing doesn’t mean that we have lost our sense of personal style or individuality. On the contrary. What it means practically is that we can spend our time and resources elsewhere, focusing on what we’re good at, while letting the experts do what they’re best at.  

We’ve seen this pivot happen many times as there are many other companies in the SaaS development industry that have done the same. By providing resources or tools for people to build on their own, or offering services that are easily integratable into your core product, companies are able to change the way we use SaaS. Big names such as Wix and Shopify have made it completely irrational for anyone to consider building their sites from scratch. Can the same concepts be applied for business and SaaS applications?

Taking on side projects might make you lose focus on your strengths. We all want to succeed and to be the best version of ourselves and it’s no different with SaaS development. We challenge ourselves daily but in the competitive SaaS development market, leaving your comfort zone can be detrimental to your success. Focus on what you’re good at. Period. You don’t want to find yourself on your wedding day ready to bling with no one to marry since you neglected your significant other all the while you were building your own dream wedding suit. 

Cost

Are you still focused on sewing your own suit? Well I think you’ll soon be open to considering other alternatives once we talk about costs and the use of one of your most valuable resources: time to market.

Inevitably, whatever the forecast is that you built in terms of budget and time to market, it is prudent to almost always allocate 50% more than expected when it comes to SaaS development. Chances are it will take you a few times to cut the design of your suit just right. So too in SaaS development, even if your budget looks great and your core team is focused you will most likely need to add an additional 50% on top to account for the unexpected. 

There is an irony in the fact that “planning for the unplanned” is close to impossible and that in retrospect, trying to calculate the total number of extra hours and dollars you’ll need to reach the market is also quite challenging. By allowing yourself the option to buy the SaaS products that are part of the 20% of your non core features could essentially allow you to present a more accurate cost analysis and to plan for your long term business goals. 

Let’s say you take into account the U.S. salaries of one UX designer, one product manager and one software engineer. You then allot a budget and timeline for research, development, testing and deployment. On top of that, you include 4 annual updates with sprints. By now, we’re easily looking at an entire year to develop at $70K cost for a single custom developed user onboarding experience. That is of course only when you are also planning to use the team for other tasks simultaneously to justify their salaries. 

Build vs. buy is not a purely financial decision because regardless of where you are in terms of development, time, not money, is your most valuable asset. Drawn out development means disengagement by your clients, boredom and lack of motivation from your team and missed opportunities. Not to mention that every time you change or upgrade your features, your engineering team will need to include maintenance in the scope of their work. 

Building means customized but when time is of the essence, think about all the missed opportunities and goals that you could have attained if you had sped up production while focusing on what you do best. Think about the time you could have spent with your future significant other, planning your big day together instead of focusing on your own single wedding suit. 

In today’s fast moving and competitive SaaS market, focusing on your core business is critical. Don’t let business agnostic features get in the way of reaching your business goals. The buy versus build debate is no longer an either/or decision to be had. By knowing what to buy and when to build you will be able to keep your focus set on the goals you were aiming to reach in the first place.

When you start by understanding your business needs, you can easily define your SaaS application’s basic requirements. You can then create a budget for your “build” option. First review the proposed timeline and then add 50% to your time and resources estimate. Now go back and reassess your initial budget while integrating SaaS product features that are “buy” options wherever you possibly can. And voila! This is your big day so make it shine!