Should you build, rent or buy your software?
The target audience of this article is any company that wants to sell its products online.
Not too long ago, the debate was whether to build or buy, but with the advent of cloud computing, the question that makes more sense now is — build or rent or buy. Lets clarify these definitions.
You build your own software, reuse open source libraries and deploy your solution on either open source servers, or paid servers. You write every line of code that is specific to your business/website. The servers/infrastructure is out of the remit of this article.
You rent software developed by someone else. You don’t write a single line of code. Blogger & Shopify are two examples of this kind of software.
You buy the software written by a big reputed company e.g. Oracle, IBM , etc. COTS (Commercial off the shelf) is often the term used for this kind of software. You then hire consultants or retrain your own staff to customise the COTS solution to fit your needs. There is an element of Build in this, but nowhere near as elaborate as the ‘Build’ option in itself.
Companies move in and out of these paradigms at fairly regular intervals (~ 5-10 years). Whatever approach a company plans to take, it is one of the most expensive decisions which will keep impacting the company bottom line for many years to come. So, it is imperative that it is discussed properly.
Is there a right approach ? Or in other words can we have some standard rules by which this decision can be made. I am sure there are many views out there on this topic, so here is one more to add to that mix.
So, what is the problem? Why is it so hard to build software? As opposed to lets say cars. The car assembly line pumps out car after car with identical quality. Why is it impossible to apply the same principle to software?
Before we attempt to come up with a framework for evaluating those choices, lets look into some definitions which have a great deal of impact on those choices.
No two softwares are identical. You can drive any Ford Fiesta or Porsche (if you prefer) in the world , and they would be identical to each other. You don’t have to learn or unlearn anything to switch cars, which makes it easy & predictable to drive any car and minimises any risk introduced by the switch.
No two software developers are identical. One of the most undervalued entities in the software industry is a ‘Good software developer’.
What/Who is a good software developer ? If I have to answer that in one line, I would say that a good software developer is someone who spends more time writing new software than fixing defects in the code developed by him/her.
Any/every software developed at any point in time will have defects. However all defects are not the same, and it is important to understand the subtle differences in the defects, if we are to fully appreciate a developer.
A technical defect (e.g., a NullPointerException) is purely a developer’s fault. Whereas a behavioural (i.e., a functional) defect is not a developer’s fault. The responsibility in the second instance has to be with the person responsible for finalising and clarifying business requirements. If you have vague requirements, you will have behavioural defects, which will only come to light once the system is put under use (either at acceptance testing or with real customers). Too late. As they say, the cost of fixing defects increase exponentially with passing time. 
In my view, a good developer is worth 10 average developers, and infinitely more valuable than bad developers. A bad developer will set you back on your business plans, and the tangible cost of that can never be fully worked out in terms of $/£.
Okay, thats all good but as a business, how does it help me make my decision ? What do I need to do to make use of all that information, and chart a course for my eCommerce venture ?
Lets look into each type of business:
Small player, offline only
This category includes the SME player (< $500million annual turnover), which has brick and mortar structure in place but there is no online presence. i.e. they are starting afresh to sell their wares online.
Selling online is not just about the technology but the business processes that go along with it. You need to not just establish stable technology to be able to successfully cater visitors, but you also need to ensure that your business processes are geared to meet the online customer and understand its nuisances. Technology keeps changing but the business process i.e the roles and responsibilities of a business user is something that stays more or less the same over a period of time.
As a small player starting out in the eCommerce venture, you should aim to establish your business processes first. Also, since you are new to the technology field, you should go for low cost option in the short term with minimal impact on your existing business. Given these constraints, the option that best fits your needs is the Rent option. You can rent the software which has already been developed by someone else, and push your own product data set through that software. This will give you a feel of the online space and at the same time, keep your capital expenditure on the lower side. While you are using a stable technology, (which you did not have to spend time developing), you can take time to develop & streamline your business processes.
This should give you couple of years to establish yourself in the online space (or not). And once you have tested the waters, you can get adventurous or not, as the case may be.
Small player, online/offline
This category includes SME players which have offline shops as well as online presence.If you are a small player, and have been operating in the online space for some time, then you must have had time to establish the business processes. So, lets assume that you have half decent business processes in place. The reason you are looking to change the technology could be that your current technology has become out of date, or you are simply wanting to grow beyond your current customer base, which your current solution is unable to support.
Either way, you need to understand your current technology team to be able to make a decision.
If you have a great technology team, then you should go for the build option using API-first model . You could start with a single API service to start with e.g. a ProductService and then ensure that this service works before applying the same principle to other services.
On the other hand, if you don’t have a high confidence in your current technical team, then you could go for Rent/Buy option. Consider, if you are able to invest in your team and improve the overall quality of the team by training or new hires.
If your business processes are complex and you have lot of customisations, then Buy is the only realistic option. With Rent option, you will eventually hit the roadblock where you are unable to do things that you need for your business, and by that time it would be too late. So bite the bullet, and buy. Or else simplify your business processes (if it works).
Big player, offline only
If you are a big player with only offline presence & no online presence (unlikely but possible), then you should invest in hiring the best technical team, and go for the Build option using API first architecture.
The most important thing for you is that your solutions are stable and scalable, and only a great technical team can ensure that.
You can also consider the Buy option, but in my opinion, the lock in introduced by the Buy option does not outweigh the advances being made in technology across the software stack.
Big player, online/offline