Don’t buy an F1 car for grocery shopping, or how to match the solution to the real needs of your business.

Business software needs are as varied as the businesses themselves. A large corporation requires something completely different to a small or medium-sized business. It’s all about matching needs and tools. In exactly the same way, you wouldn’t choose a sports car to take your family on a holiday trip.

If you don’t need a functionality – you don’t have to have it in the application. Just as a lack of capabilities can be a problem, an excess of options is not an advantage either. You don’t need a massive, complex system to handle relatively simple business processes, just as you don’t buy a sports car to go grocery shopping. Properly matching the application to business needs is a key to high effectiveness.

Large company – large system, small company – small system?

If only the issue of matching business software were that simple. The size of the organisation is just one of the factors that influence how to choose or design the right application.

The second important factor is primarily the level of process complexity within the organisation. Even a company that is large in terms of employee count, but operates on relatively simple processes, will not need a highly complex application with many functionalities.

How to match an application to your needs?

The most important thing is to determine needs – real ones, not wishful ones. Properly mapping the processes in the company is a necessary step to understand the organisation’s needs regarding the planned application. At this point, the temptation arises to build something more, with the company’s growth in mind. This might seemingly appear to be a good idea, but in practice, it is easy to overinvest this way, building a system that is too large and complex, for needs far exceeding current processes. It is good to consider the growth perspective for the next 2-3 years, but no more.

It becomes more important that the system can be modified, expanded, and developed. This is where the advantage of software written specifically for your company over “off-the-shelf” systems reveals itself. When a new business needs arises, you simply commission the agency to include it in the subsequent modules of the system.

Value-Driven Design. You may have already heard this term. This is a concept according to which, already at the application planning stage, we take goals and costs into account. We start with specific business questions, rather than technical ones, e.g., how to improve customer retention?

Also, pay attention to the application’s TCO (Total Cost of Ownership). The purchase itself is not the end, after all. Ask yourself the following questions:

• What kind of team will be needed to operate and maintain the application? Will you need external support for this?
  
• What load on the application do you anticipate? Take into account the number of users, frequency of use, number of logins – everything that determines the application’s demand for performance.
  
• Which processes are currently a bottleneck for the company?
  
• How dependent is your organisation on the application? Do downtimes literally “shut down the company”?

The answers to these questions will allow you to understand the business needs in terms of performance and maintenance. It may turn out that you don’t need a 2h SLA, which significantly increases the TCO, and, for instance, a 6h one will be perfectly sufficient.

The entire selection and planning process should focus on the needs of your organisation. If the technical aspect is a challenge for you, we are here to help with this process.

What happens if you buy the F1 car anyway?

There is a risk that you will ultimately buy a solution whose capabilities far exceed your needs. You can be sure that in such a scenario you will overpay, and in several ways.

First of all, the purchase of the application itself will be more expensive. Large systems take longer to build, require more complex planning, and involve a larger team on the agency’s side. They are also more costly to maintain, requiring stronger infrastructure.

And speaking of infrastructure: by choosing the “F1 car”, you also expose yourself to higher costs associated with maintaining the operation of your own infrastructure. It will be subjected to heavier loads, which will increase the TCO. In the same way, it will increase the maintenance cost if the application runs in the cloud.

The risk of overpaying for a project whose capabilities you will only partially use is quite real. We want to help you avoid such a risk. Consult your idea with our team – let’s get in touch!