Introduction
If you are running a start-up or a large enterprise, a common question is whether to buy pre-existing, already constructed (COTS) systems or software or whether to build them yourself. For those who work as developers, there is a strong tendency to want to make it themselves. It is typically a big 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 any pre-existing system or how a strategic combination of both would 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.
Buying
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, you should consider a few areas at a basic level. Let’s break these down:
Price and pricing model
At an early glance, purchasing software can appear inexpensive, especially compared to developing time costs. Small businesses and start-ups have some efficient solutions available at low prices.
However, as is often said that ‘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, but if you can afford more frequently, a vendor will offer you a proposal 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, most SaaS and PaaS companies charge by usage. Some risks are getting involved with a pricing schema that looks good for your company at its current size. Often expenses can grow as your company grows, not necessarily at an ideal rate. If you depend on the system for most of your needs and if the business grows, the cost of switching to a custom platform could be much higher than initially.
Support and regular updates
Integration and setup challenges will always exist, no matter how generalized a platform is. One reason why many companies choose to go with popular products is that there is standardization to how the product is handled. If there are issues, the support staff is available in many cases. 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 frequently 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 from which you can get your answers?
- How adaptable is it?
We have worked with many such third-party systems, and sometimes our clients, as they grow, begin requiring much more integration and customization to these platforms. Since the PaaS and SaaS companies are much less likely to alter their products to each of their client’s specific needs and would rather keep a standardized product development pipeline, it has been a challenge in such cases. Hence, migration from such platforms to custom solutions has been much higher at that later stage.
(Possible graphic of companies reaching certain milestones [years in operation, or users, or something] and then the rate at which they decide to convert to custom platforms. Also, some examples of companies who made the switch.)
If a product is open source, it could be quite possible to modify it, but the developers would need to be consulted on this process before beginning. In many cases, you have no access to the code, so modification is complex, and you may need to rely on whatever is included in the APIs and any 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 is required to get existing systems functioning with existing systems. This involves quite a bit of research time and the 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 the product and your system is crucial. Remember that those working for the vendor want to make the sale go smoothly but may promise things that the product cannot do; make sure your teams go over it entirely.
Scalability
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 has restrictions that will make it infeasible if you grow or integrate your existing systems.
Compatibility
Compatibility can be an issue. Many products have problems 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.
Portability
Getting stuck in a platform that does not easily allow moving information or data out of it can result in some future extreme costs, and the work involved can be prohibitive. You may find yourself locked into using a product under license 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 traditional indexing that would make sense through a data exchange process for another product?)
One possible solution is containerization, wherein the system runs as a discrete unit that can be ported from one platform to another. However, you risk the data being limited to that platform if there’s no easy way to get it out.
Building
The apparent alternative to purchasing software is to either build it yourself or hire someone to make it for you. Let’s go over some of the areas you need to consider.
Expense
Custom software is generally reasonably expensive to build, depending on the requirements. It requires hiring designers, developers, testers, project managers, and a cloud ops team. However, in the long run, assuming it was built well, it can pay off as you are more likely to get precisely what you need or want.
It is important to note that there are ongoing costs, such as maintenance and upgrades, so staffing needs to be maintained.
Flexibility
Because you are designing and developing it from the ground up, you have much more flexibility than you would from purchased software. If it is your software, updates and enhancements are under your 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 to have an advantage over your competitors who use canned solutions; you can make changes much faster and adapt to market needs with great agility.
Maintenance
You can react quickly if a bug is discovered, but it is all on you to ensure it is taken care of.
If the technology is crucial to your business, this can have advantages over purchased software. However, support is only as good as your team can provide. Having redundancy built into your technical teams with appropriate processes is essential. It would help if you were sure that the knowledge is transferred across multiple team members to avoid any potential risk in case somebody leaves the team.
Longevity
Your software or systems can last a very long, so it is essential to attend to scalability.
Make sure the development team makes room for unexpected changes. Your company’s needs can grow (assuming you want this to happen). This requires not cutting corners. As a result, the development cost will likely increase during the early stages. The mindset of “quick and dirty, but it works” can cause problems down the road. However, at the very least, you know your systems; it’s much easier than trying to amend someone else’s software (which may not even be possible under their license).
Without scalability, you could create a system that still works but is increasingly obsolescent. It is possible to become dependent on a structure that has been around for years, long past its ideal lifespan, but cannot be replaced because it is embedded deeply within your business processes. For example, many large institutions still rely on and maintain mainframes and require COBOL programmers simply because the cost of change is impossible. 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 a timeline or budget restriction; finding a delicate combination of Buy and Build would be beneficial.
Businesses that want to have control over intellectual property need to consider the repercussions of subscribing to third-party systems very closely. Not to mention there is a dire need for scalability and flexibility. In such cases, it is better to have most of the core infrastructure custom built except for a few redundant features, such as, in most cases, Account Management, AI capabilities, Payment Systems, Video Management Systems and Players, Document Management Systems, etc. If it is not a core value for your business, you are building these in a custom fashion unless you are in one of these verticals as a core offering.
Another essential factor to be evaluated while using a third-party system for features that are not core is how easy it would be to switch to another similar provider if things go awry with the current one. Good preparation for this is to architect the system appropriately from the beginning so there is enough decoupling of the third-party scenarios. 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. Several sound existing e-commerce systems can help you get set up quickly and integrate well with simple websites like WooCommerce or CloudCraze.
For most small businesses, this route 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 the way you want it to work. You have much more agility with a custom-built system and the freedom to make the necessary modifications.
On the other hand, building an e-commerce platform is not easy. You may need quite a bit of expertise and labor to run and 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 straightforward 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 several 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. Other popular CMS platforms, such as Expression Engine, and many others, are available for purchase.
However, not all content is web content. You sometimes need a powerful back-end system that can handle inventory processing or 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 looking 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, frameworks such as Django CMS (based on Python) and Refinery CMS (based on Ruby on Rails) can be used to hit the ground running with a lot of essential features needed in a standard CMS.
Customer Relationship Management
This area is 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 use some less-expensive but equally powerful options such as ZenDesk.
Typically, building these is unnecessary unless you wish to create something out of the ordinary.
Platform as a Service
Platform as a Service, or PaaS is a popular method of managing complex business operations without having to purchase complete 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 anyone logs into the system.
Other advantages include eliminating the need to spend much money on redundant hardware that may or may not work with all of your software. Within PaaS systems, hardware and software are pretty much always compatible. The vendor almost always handles the maintenance of this.
There are, however, some drawbacks. It is possible to have problems with vendor lock-in. It is easy to end up dependent on one platform without the ability to migrate to a different company easily. Scalability can also be limited; sometimes, it’s not easy to expand.
Maintaining expenses can also be a challenge. With hardware, there’s a fixed cost; other than maintenance (or obsolescence), 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.
Conclusion
It cannot be easy 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 the problem you want to solve. Using the above criteria should help you make the right decisions or ask the right questions.
However, the most significant 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, it’s a good idea to purchase some simple solutions and move from there.
