Should You Buy or Build Enterprise Software? Let’s Look at Pros and Cons
Enterprises use anywhere from 300 to 600 apps on average, with really large organizations (10,000+ employees) spending as much as $224.8 million a year on SaaS products. At the same time, the price of a custom-made enterprise software application starts from $50,000 to $100,000, with the average solution costing $350,000 to $550,000 a year to develop and/or support.
These averages are of little help when you need to decide whether to build or buy a software application. Business apps vary in terms of their specificity and the assortment of features they offer. Some may be too narrow or too broad for your needs. What do you do then? Here is an algorithm that can help you make up your mind.
Build vs. Buy: A Decision-Making Framework
The following analysis will be most useful to companies with big budgets looking to optimize their app spend.
Also, it mostly pertains to situations when the answer is not obvious. A lot of the time, it makes little sense to reinvent the wheel: for example, when the technological gap you’re trying to fill can be easily solved by a standard solution widely used in your industry.
The first thing to do is to pull out a calculator and estimate the total cost of ownership (TCO) of your “buy” product vs your “build” solution. It is estimated according to the following formula (you can run your estimates per month or per annum):
Build TCO = Development Costs + Management Costs
Buy TCO = Subscription Fee + Associated Operational Costs
While SaaS pricing is usually fixed, the price of a custom software product depends on a number of factors. The development team will normally do their best to meet your budget, but keep in mind that the exact cost of developing an app may be hard to predict.
Let’s say you estimated the approximate cost of ready-made vs custom-built software and—oops!—it’s a tie. Then you can take the following factors into consideration.
A Build vs. Buy Software Matrix
What You Get | Build Solution | Buy Solution |
---|---|---|
You get all the features you need (100%) | V | X |
An ability to add very specific new functionality to the app | V | X |
Predictable cost* | X | V |
You can add any number of users for free | V | X |
Quick launch | X | V |
Unique capabilities that give you competitive edge | V | X |
You can gauge other companies’ previous experience with the app | X | V |
*Building a custom app typically costs more upfront, while SaaS fees might accumulate to a large amount over time.
It would be unhelpful to merely count the number of pros and cons of a build vs buy solution—sometimes, a single factor informs your entire decision. For example, you might be on a tight budget. Or you need the application ASAP and can’t wait months for it to be developed.
The above matrix is meant to give the decision maker an idea of what they get with an out-of-the-box product vs a custom-built product.
It also helps to understand the general philosophy behind the two approaches.
Think of it as paying taxes in the country you live: everyone pays their share of taxes, but the state decides where that money goes. Sometimes you like how your ‘tax dollar’ is spent, and sometimes you don’t. SaaS (software as a service) subscriptions work in a similar way. All users chip in to keep the software running and to get the features they need. But will you get the feature you want, when you want it? That’s a good question. You, as the user, have limited control over the vendor’s decisions.
At the same time, with custom-built software you get to make all key decisions regarding your application: which features should be developed and in what order, what part of your budget should be allocated to testing—even what your app should look like! You get to make those decisions, but a purpose-built application requires much more involvement on your part.
Building Software: Pros and Cons
If you have looked at the general ‘build vs buy software matrix’ and are still unsure what to do, here is a more nuanced analysis. Let’s discuss the pros and cons of building your own custom application in more detail.
Pros | Cons |
---|---|
The solution has all the right features. | You’ll need a stakeholder at your end to communicate the requirements. |
No need to pay for the functionality you don’t use. | It may take a while to build the solution. |
It’s easier to integrate the app with your system. | The cost and timeline may be tricky to estimate. |
All data stays in your company’s ecosystem. | You will be the one responsible for further maintenance. |
Buying Software: Pros and Cons
It might be tempting to buy an out-of-the-box SaaS product and call it a day. However, this decision comes with its own risks. Quite a few clients have told ObjectStyle over the years that they feel stuck with the SaaS product they are using, but quitting/migrating is hardly an option because they don’t even know how to approach this daunting task.
So we would recommend thinking very carefully before committing to a SaaS product. Here are some risks and benefits to take into consideration.
Pros | Cons |
---|---|
You get the solution quickly. | The off-the-shelf solution may be missing some functionality. |
No need to manage the development team. | You may still need to write integration code to plug the app in your system. |
It may be cheaper than building a custom application. | You may need to pay for each new user. |
No need to support the application. | There may be security concerns, especially if the app has access to sensitive business data. |
A potential benefit of buying off-the-shelf software is that, with it, you’re buying industry experience. The software product can introduce the industry’s best practices into your organization. Let’s say your company just grew from 20 to 100 people and you need to update your HR processes to handle the new headcount. Software products for orgs with 100+ people might have some time-tested HR processes baked in the app by default. On the flip side, if you want to differentiate yourself with your HR process, you better build a custom, innovative solution.
Software Vendor Selection Process
Whether you are more inclined to buy a ready-made product or create a custom application, you will need to go through the vendor selection process. Below we offer a comprehensive framework that our clients and ourselves have used in the past for these purposes.
And now let’s dive deeper into each of the steps.
Step 1. Make a list of features
While you’re making a list of capabilities you are looking for in a solution, it helps to differentiate between must-have, should-have and could-have features. (It’s important to put integrations with your existing systems into the ‘must-have’ group, since you want to minimize silos.) Try to keep your list relatively small, because it will be hard to evaluate potential solutions against a really long spreadsheet of ‘wants’.
If you have a vague idea about what the app should do (because it was requested by, say, your HR department), someone will have to gather requirements by interviewing those who will be using the app.
Also remember to gather non-functional requirements, that is, specifics linked to product security, speed, access management, API availability, and other vital technical characteristics. While some companies skip this step, it’s not a good idea to do so. If you don’t account for non-functional requirements, you may run into unpleasant limitations down the road (for instance, that you can’t integrate the app with another important app in your ecosystem), and it will be too late to change your mind.
Step 2. Make a list of vendors
You can do this for both SaaS providers and custom software vendors. For example, when ObjectStyle was looking for a CMS product because we needed to migrate from our Java-based custom-built system (we wrote a detailed case study about that), we made a simple spreadsheet that listed potential vendors in one column and contained information about the features they provide. It looked approximately like this:
Now, you can make a similar chart only for potential custom software developers. For this spreadsheet, you can look for things like:
- Does the vendor specialize in your type of application?*
- Where are they located?
- Reviews and case studies
- Success stories relevant to your industry
- Etc.
*For example, ObjectStyle has a lot of experience building complex software systems for enterprise companies. Other vendors may specialize in web design, mobile app development, etc.
Step 3. Fill in the blanks
After you make initial lists, you will need to fill in the missing information. In our own experience, the fastest way to do it is to reach out to the vendor’s pre-sales team and ask them for answers. If you are more of a solo/independent type, you can use Google, review websites and relevant forums to find the missing pieces.
Step 4.1 (SaaS) Request a demo/trial
When a shortlist of potential SaaS products is ready, you should see them in action. Some products offer a free trial. Others will do a demo for you or offer a money-back guarantee. It makes sense to invite those who will be actually using the app to the demo/free trial.
Hint: think of a typical workflow or a process that you would like to complete with the app. Go over the same steps in each application to see how they cope with the same process. If you keep it uniform, it will make it easier for you to compare your options.
Step 4.2 (Developer) Request a quote
When it comes to a quote for a custom application, the good news is that you won’t have to go over lengthy feature descriptions because you will be the one calling the shots on what features to include. It really helps to have an RFP (request for proposal) document ready because it’ll help the vendor craft a more accurate proposal.
However, the proposal is only a rough estimate. Some software projects are difficult to estimate without investing significant time (up to two or three months) in research and PoC development. Therefore, if you are taking the custom software route, it really makes sense to invest in the Discovery phase.
What is the Discovery phase? It’s a relatively small and inexpensive project the developer undertakes to see if the project is feasible in the proposed time and for the proposed budget. During this phase, the developer will most likely create a PoC (proof of concept) solution, which you can then evaluate to see if it meets your criteria. – This, in a way, is a substitute for taking a SaaS product for a test drive.
Another benefit of going through the Discovery phase is that you can get a sense of what it’s like to work with a particular developer. It’s good to know that in case you end up doing the entire project with them.
Step 5. Do the final assessment
Once you have gathered all the data, you can compare your options side by side. You can see which ready-made product or a proof-of-concept solution best meets your needs and your budget.
Final Thoughts
At the end of the day, the choice between building or buying a software piece boils down to which proposed/tested solution best satisfies your needs. And if we are talking about some really complex and expensive software, it’s better to perform a thorough evaluation of all your options before committing to a vendor—the price for switching the provider afterwards can be prohibitive.