Software for resale – what you need to know

In today’s world, an increasing number of companies that develop customer-specific software have adapted, focusing instead on developing and selling product software. This approach has many benefits, 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 the need to build in flexibility for future product changes – products need to be durable 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 more commonly called ‘software productisation’, is likely to be higher.

Below are some points illustrating why building a software product for resale involves more effort than a one-off bespoke software implementation.

Custom software

Custom software is software that is tailored to the needs of one specific customer to satisfy 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.

Software product for resale

Standard software is designed based on the needs of a specific market, not an individual client.

Identifying and separating 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 has to be established from the start.

The training, sales and delivery process 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 must be in place – developers must write the code in a standardised way, enforced on them by the solution architect.

Agile methodology is more appropriate as not all requirements will be known from the start. This means that the budget might not always be 100% clear.