In today's world, more and more companies that develop customer specific software have identified a need to change to developing and selling product software. There are many benefits of this approach, such as recurring revenue and reducing business risk. These are, however, not the subject of this article.
What many companies do not realise is that producing software for resale will need a different development approach. The main reason is the need to build in flexibility for future product changes - products need to be durable and yet flexible enough to absorb and embrace these changes with minimal impact on the business logic. As a result, the costs of developing software for reuse, resale or what's more commonly called, 'software productization', are likely to be higher.
Below are some of the points that illustrate why building a software product for resale involves more effort than a one-off bespoke software implementation.
How does the software differ when developing for one client or for resale?
Custom software is software that is tailored to the needs of one specific customer with the purpose of satisfying that customer.
This provides a specific solution per customer on a per project basis. Projects are executed independently from each other and differ in budget, technology and functionality. Reusability of existing components between various clients exists, but custom implemented features are larger than standard features.
The project methodology is usually based on the 'waterfall' approach (all requirements are gathered upfront) so costs can be we well estimated.
The development standards can vary between various programmers joining the projects.
Software Product For Resale
Standard software is software that is designed based on the needs of a specific market, not an individual client.
Identification and separation of product core features and customisable modules is the most important part of the requirements process. The standardised parts of the project (the similarities of customers'; wishes) have to be identified. These constitute a set of features that form a common structure, from which a stream of customised modules can be efficiently produced. If this is not planned well, the result can be either the duplication of features in customised modules or an inflexible core product that will have to be changed in due course.
A plan of ongoing upgrades, stage rollouts and re-implementations of the so called product roadmap have to be established from the start.
The process for training, sales and delivery needs to be consistent and repeatable.
Solution scalability, efficiency and comprehensive testing will need to be more comprehensive than in the case of the individual software build.
A solid technical architecture and strong development processes have to be in place - developers have to write the code in a standardised way, enforced on them by the solution architect.
Agile methodology is more appropriate as not all of the requirements will be known from the start. This means that the budget might not always be 100% clear.