In the last few years, we have suddenly seen a spike in the usage of the term software platform. All types of software applications started getting called platforms. But the term platform has a specific meaning which differentiates it from technology/software applications. A platform enables other software applications to run on it, mostly to be used by end-users. In other words, we could say that a platform by itself is useless to the end-users unless it is programmed or customized for specific usage. WordPress, Moodle, Google Forms, ODK, Avni - they are all platforms. Google Docs, MS Paint are not platforms as they are mostly consumed directly by the end-users. Though the ease of customization can blur the lines between the user and the customizer and the same person may be playing both roles.
It was important to establish this distinction so that we can answer the more relevant question - how should we decide when to use a platform and when to develop a bespoke software application? Bespoke means custom-made—made based on the specifications of the person ordering it, as in a bespoke suit (from dictionary.com). The diagram below shows two distinct scenarios.
The essential tradeoff between these two options is cost, time, risk, and requirement match. A list of tradeoff involved are as follows:
| Bespoke application | Customization on platform | |
| COST, TIME | Requires software development hence high costs, time | On the right platform, an order of magnitude is smaller compared to a bespoke application. |
| RISK |
Uncertainties in quality being poor, cost, and time overruns of the software development undertaking. Often getting all three right has been difficult for most projects.
Finding the right technology development organization (important to consider that domain expertise doesn't travel from high resource to low resource context) |
Quality can be pre-determined. Platform quality matures over time.
The extent of requirement fit offered by the platform has to be determined at the start itself, which could be technically challenging.
The roadmap of the platform is determined by the third party. Depending on the platform roadmap too much, could be a double-edged sword. On one hand, you get features for free. On the other, they may take longer to arrive than expected. |
| Requirement Match | The end solution will meet all your requirements. In control of your destiny for subsequent development, albeit it will continue to require resources. |
Cannot expect a 100% match, but one can aspire and achieve 90-95% in most situations. A solution developed on platforms, with the platform-provided user interface, may require higher levels of training for end-users. |
Let us look a bit deeper into what this means more specifically for community and field programs. Such programs lack the following resources.
- Funds available to use for technology deployment
- In-house technical skills to develop such solutions
Hence the best solutions are those which require fewer funds and can be managed with technical skills available within the organization, while largely satisfying the requirements. With these key parameters of evaluation in mind let us see the matrix below which presents various scenarios and our recommendations.
- Whenever our functional requirements are commonly shared by a large number of people in various disciplines - the widely available consumer platforms can serve such needs.
- When additional features are required that are specific to the domain of work, we have two options. Either use a platform or get the software developed in-house (via a software development partner). Unless the features required are not present in the platforms available, going for bespoke software development incurs much higher cost - with the same result. Additionally, platforms afford you the ability to perform customizations in-house as they require much lesser software development skills. Hence you are less dependent on your software partner (for certain customizations one may still require a software vendor's help, but with good platforms, they are less and keep getting lesser over time).
- When one finds oneself in a situation where only very few functionalities required are missing the platform - which is quite often the case. One can choose the bespoke application route or use the platform without the missing functionality. We have observed that there is an additional route available with open source platforms where one of the following may work out.
- You may check the feature's availability in the product roadmap of the platform. Open source products share their roadmap publicly.
- You should connect via the community route and work out a mechanism to add the functionality to the product roadmap or even get it done by paying a small amount (which may be still much lesser than developing a bespoke application).
ps: Lastly, the question mark space may be of academic interest to some. Why does such a blank space exist? As we understand, it is difficult for platforms to move up the feature ladder without moving right in customization complexity as well (and vice-versa). Hence where a platform places itself is a strategic tradeoff made by the organization/people behind the platform. Overall one should always expect the blank space.
Author: Vivek Singh
Published On: 04 November 2020