In today's world, an increasing number of companies that develop customer specific software have adapted, focusing instead on developing and selling product software. There are many benefits to this approach, such as recurring revenue and reducing business risk.
What many companies do not realise is that producing software for resale will need a different development approach. The main reason is due to 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 cost 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.
Custom software is software that is tailored to the needs of one specific customer with the purpose of satisfying that customer.
This provides customers with specific solutions 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 well estimated.
The development standards can vary between various programmers joining the projects.
Standard software is software that is designed based on the needs of a specific market, not an individual client.
The identification and separation of core product features and customisable modules is the most important part of the requirements process. The standardised parts of the project 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 either be the duplication of features within customised modules or an inflexible core product that will have to be changed in due course.
A plan of ongoing upgrades, staged rollouts and re-implementations of the so called product roadmap have to be established from the start.
The process used for training, sales and delivery needs to be consistent and repeatable.
Solution scalability, efficiency and comprehensive testing will need to be more thorough than it is for 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.