Buy vs Build: Finding what is right for you

Buy vs Build: Finding what is right for you

by Sreejith Partha

If you are running a startup or a large enterprise, a common question is whether to buy preexisting, already constructed (COTS) systems or software, or whether to build them yourself. For those of who work as developers, there’s a strong tendency to want to build it themselves. It is typically a large reason that they are in this field in the first place. However, from a business perspective it’s necessary to do a cost-benefit analysis to determine whether the time it takes to create a product is worth it compared to many pre-existing systems, or how would a strategic combination of both be beneficial.

Let’s start with a broad level view, and then we’ll break it down into more specific types of software or systems.


Before building new software, it is generally a good idea to determine whether something already exists that can do the job you wish it to do. If it does, at a basic level, there are a few areas you should consider. Let’s break these down:

Price and pricing model

At an early glance, purchasing software can appear inexpensive, especially if compared to the cost of developing time. For small businesses and startups, there are some very practical solutions available at low prices.

However, as is often said, you get what you pay for. You can find some solutions that will handle the bare minimum of what you need for a low rate to get started. If you can afford more, in many cases a vendor will offer you an offer to upgrade for a better product.

It is important to note that the cost of purchasing software has to be carefully considered for a reasonably long term. While the numbers may look good up front, most SaaS and PaaS companies charge by usage. There are some risks getting involved with a pricing schema that looks good for your company at its current size. Often expenses can grow as your company grows, and not necessarily at an ideal rate. If you decide to depend on the system for majority of your needs and if the business grows, the cost of switching to a custom platform could be much higher than it was initially.

Support and regular updates

No matter how generalized a platform is, there will always be integration and setup challenges. One reason why many companies choose to go with popular products is that there is a standardization to the way the product is handled. In many cases if there are issues, there is a known support staff available. You may have a dedicated Customer Service Manager or not. You will likely wish to verify this early on in the process.

If a company provides support, it’s usually a good idea to look beyond their marketing materials; find others who have used the product and gauge their experience when something goes wrong. How frequent do they release updates and fix issues? What happens when there is an upgrade? Will it affect any of your existing systems? Will they support migration from old platforms to new ones? How big is the community or its users where you can get your answers from?

How modifiable is it?

We have worked with many such third-party systems and sometimes our clients, as they grow,  have started requiring a lot more integration and customization to these platforms. Since the PaaS and SaaS companies are much less likely to alter their products to specific needs of each client and would rather keep a standardized product development pipeline, it has been a challenge in such cases. Hence, the effort of migration from such platforms to custom have been much higher at that later stage.

If a product is open source, it could be quite possible to make modifications to it but the developers would need to be consulted on this process prior to beginning. In many cases, you have no access to the code, so modification is difficult and you may be dependent on whatever is included in the APIs and Off-the-Shelf features.

Purchased software, in most cases is rarely ready to go “out of the box.” This is especially the case for larger companies. A great deal of configuration to work with existing systems is required. This requires quite a bit of research time, and dedication of resources. If you are working with a third party providing these resources, don’t think you won’t be charged for this time. Also finding people who understand both the product and your system is absolutely crucial. Remember that those working for the vendor want to make the sale go smoothly, but may promise things that the product simply cannot do; make sure your teams go over it fully.


If you purchase a product for your company when it is small, will this product handle your growth, or does it have baked-in limitations? With purchased software, you may suddenly see yourself needing to upgrade at a very high cost, or you may find that the product itself has limitations that will make it infeasible if you grow or to be integrated with your own existing systems.


Compatibility can be an issue. Many products have issues communicating with other products. If they have APIs, one might want to look at how robust they are. Working with your developers Business Analysts, and SMEs is crucial to determine whether they will meet these needs.


If you get stuck in a platform that does not easily allow moving information or data out of it, this can result in some serious future costs, and the work involved can be prohibitive. You may find yourself locked into using a product, under license, quite simply because data cannot be shared.

Make sure you understand how data can be exported. How is it stored? Is it available in standard JSON format? (And if so, does the data use any kind of standard indexing that would make sense through a data exchange process for another product?)

One possible solution to this is containerization, wherein the system runs as a discrete unit which can be ported from one platform to another. You do, however run the risk of the data being limited to that particular platform if there’s no easy way to get it out.


The obvious alternative to purchasing software is to either build it yourself or hire someone to build it for you. Let’s go over some of the areas you need to consider.


Up front, custom software is generally reasonably expensive to build depending on the requirements. It requires hiring designers, developers, testers, and project managers and cloud ops team. However, in the long run, assuming it was built well, it can pay off as you are more likely to get exactly what it is you need or want.

It is important to note that there are also ongoing costs, such as maintenance and upgrades, so staffing needs to be maintained.


Because you are designing and developing it from ground up, you have a great deal more flexibility than you would from purchased software. If it is your own software, updates, and enhancements are under your own control. Vendors are typically unwilling to make quick changes based on a customer request. If it is yours, you can have a much smoother modification process.

You also have the potential for having an advantage over your competitors who use the canned solutions; you can make changes much faster and adapt to market needs with great agility.


If a bug is discovered you can react quickly, but it is all on you to make sure it is taken care of.

If the technology is crucial to your business, this can have some advantages over purchased software. However, support is only as good as your team can provide. It is important to have redundancy built into your technical teams with appropriate processes in place. You need to be sure that the knowledge is transferred across multiple team members to avoid any potential risk in case somebody leaves the team.


Your software or systems can last a very long time, so it is very important to attend to scalability.

Make sure the development team makes room for unexpected changes. Your company’s needs can grow (I take it you want this to happen). This requires not cutting corners. As a result, the cost of development will likely increase during the early stages. “Quick and dirty, but it works” can cause you problems down the road. However at the very least, you know your systems; it’s a lot easier than trying to amend someone else’s software (which may not even be possible under their license).

Without scalability, you could find yourself creating a system which still works, but is increasingly obsolescent. It is possible to become dependent on a structure that has been around for years, long past it’s ideal lifespan, but cannot be replaced because of it being embedded deeply within your business processes. For example, many large institutions are still relying on and maintaining mainframes and requiring COBOL programmers, quite simply because the cost of change is insurmountable. This is not unusual. Wait! did I mention “COBOL”?

Best of both worlds

There are times when the requirements of a project demand the development of a custom system that could sustain and scale for a long time. Couple it with timeline or budget restriction or both, it would be beneficial to find a delicate combination of Buy and Build.

Businesses who want to have control over intellectual property would need to consider the repercussions of subscribing to third party systems very closely. Not to mention there is dire need for scalability and flexibility. In such cases, it is better to have majority of the core infrastructure custom built with the exception of few features that are redundant, such as in most cases, Account Management, AI capabilities, Payment Systems, Video Management Systems and Players, Document Management Systems etc. Building these in a custom fashion if it is not a core value for your business, unless you are in one of these verticals as a core offering, of course.

Another important factor to be evaluated while using a third-party system for features that are not core, is that how easy it would be to switch to another similar provider if things go awry with the current one. A good preparation for this is to architect the system appropriately from the beginning, such that there is enough decoupling of the third-party systems. In that way, moving from one system to another similar would not be a nightmare.

Variations by type

E-commerce systems

When setting up an e-commerce system, it can be very tempting to go with some pre-existing platforms. There are a number of good existing e-commerce systems that can help you get set up quickly, and can integrate well with simple websites, such as WooCommerce or CloudCraze.

For most small businesses, this is a route that makes a good deal of sense. However, typically as can happen you may wish to expand beyond what these platforms can provide, so you may be considering creating a custom system. Many packages do not have the flexibility to manage your interface in the way you want it to work. You have a lot more agility with a custom built system and you have the freedom to make modifications you need.

On the other hand, building an e-commerce platform is not easy. You may need quite a bit of expertise and labor to be able to not only get it running, but also to maintain it. The real issue with e-commerce comes down to cost.

If you are a small business and are simply trying to get started, it’s a good idea to go with a package until a time comes when you feel you need to expand.

Content Management Systems

WordPress pretty much dominates this market. Almost 1/3 of the web uses it. The reason is that it is very easy to create professional looking sites in a shorter amount of time. However, it is not without its flaws: one of the possible flaws of using WP is its dependence on PHP which has a number of issues, ranging from slowness to security issues. Most of the latter have been accounted for in recent versions, however speed can still be an issue. There are other popular CMS platforms, such as Expression Engine, and many others which are available for purchase.

However, not all content is web content. You sometimes need a powerful back-end system that can handle processing of inventory, or handling management of work from one team to another. These may use a web interface, but typically these are not going to be available for purchase out of the box, so you may wish to build one. It is important to note that building one’s own CMS is a somewhat large task. It’s worth taking a look at what sort of content you wish to manage; if it’s a simple list of items, WP is possibly appropriate. If it’s a complex workflow it may make sense to build one yourself. Although, a custom CMS could be needed in that case, there are frameworks such as Django CMS (based on Python), Refinery CMS (based on Ruby on Rails), that can be used to hit the ground running with a lot of basic features needed in a standard CMS.

Customer Relationship Management

This area is pretty much dominated by SaaS applications such as Salesforce, or Hubspot CRM. While one could build one on their own, this would depend on whether one wishes to make a regular investment into these popular platforms (which don’t come cheap). In this case if you are running a small local operation, you can either build it yourself or you can use some less-expensive but equally powerful options such as ZenDesk.

Typically, building these is not necessary, unless you wish to create something out of the ordinary.

Platform as Service

Platform as Service or PaaS is a popular method of managing complex business operations without having to purchase full onsite systems. It can be a very appealing option for many businesses, particularly those on the smaller side. It makes for easy collaboration with remote teams. Due to its cloud based nature, work can happen anywhere when anyone logs into the system.

Other advantages include the elimination of the need to spend a lot of money on redundant hardware which may or may not work with all of your software. Within PaaS systems, hardware and software are pretty much always compatible. The maintenance of this is almost always handled by the vendor.

There are, however, some drawbacks. It is possible to have problems with vendor lock in. It is very easy to become dependent on one particular platform without the ability to easily migrate to a different company. Scalability can also be limited; sometimes it’s not easy to expand.

Maintaining expense can also be a challenge. With hardware, there’s a fixed cost, and other than maintenance (or obsolescence) so you don’t need to keep getting bills. Many PaaS vendors charge by usage. It is generally a good idea to look at this in terms of cost over time.


It can be difficult to decide whether or not to build or buy a software package. Generally it is best to look at the nature of the question you want to answer or problem you want to solve. Using the above criteria should help you make the right decisions.

However, the largest factor almost always comes down to budget. In an ideal world, it would be great if we could build everything to specifications, but in reality this is typically unfeasible for most businesses. If you are starting off, it’s a good idea to purchase some simple solutions, and move from there.

Sreejith Partha (Sree) is the CEO of Practical Logix, leading an outstanding engineering and product team. He enjoys being hands on, when it comes to product strategy, architecture and processes. Sree has cultivated a culture at PL where no one is secluded from the bigger picture, helping the stakeholders trickle down the passion of their brand to every team member, producing a better outcome.

Leave a Reply

Your email address will not be published. Required fields are marked *