Cookie Consent

By clicking “Accept”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.

Cookie preferences

How the business case can put constraints on the development strategy and vice versa

February 16, 2023


Software development has become a crucial aspect of modern businesses. However, the disconnect between the businesspeople and developers is a major obstacle in achieving the desired outcome. This blog post highlights the importance of direct communication between businesspeople and developers and the constraints that the business case may put on software development strategy and vice versa.

A company with a business decision to make

This fictive example is based on different experiences I’ve had working with different organizations. It is intended to illuminate how a business decision puts constraints on which software development strategy needs to be chosen and how that decision in turn put constraint on the business. Other decision could be more optimal depending on context, but this is not the point of this post.

The company

The software development company started out with a single customer. To organization could handle the business growth when the customers increased with a second client, soon followed by a third. The market forecast indicated that the potential number of customers could increase to well over ten during the coming years there was decision to be made about what the business case should be. Two potential cases were put forward to answer this question.

Case A: To deliver custom software updates and new features as fast as possible to a customer

In this business case the company focus on deliver new custom software features and updates faster to customers than competitors. This would make it difficult for competition to gain foothold on the market and in this way gain market shares on a growing market. To support this business case; one development strategy could be to keep each software solution unique for each customer. In this way, a modification or update could be made fast for a specific customer without any potential negative impact on other customers. This strategy puts the following constraints on the business:

* It become difficult to scale the number of potential customers beyond a certain point when the cost of maintaining multiple unique solutions become costly.

* If the code hasn’t been updated in a while it can become costly for a team to get up to speed with the code base, even for a smaller change. This might require the company to charge a hefty sum from the customers even if the change is small and even if a similar change has been done for other

* Specialised competence must be retained in the company. With several unique solutions it becomes important to keep at least one person for each one that understands the inner working. Otherwise, the cost of a team starting to learn how the solution works from scratch can be high.

Case B: Capability to deliver one code change to multiple customers at once

This business case will require a common software foundation that is the same for every customer with customer adaptations on the top. The upside is that one new feature or fix can be sent out to all customers at once which means that the business can scale to accommodate a larger number of companies that possible with case A. It would also make it possible to develop a feature once and charge each customer separately for it. With all developers working on the same software the competence and knowledge is spread out and thus the risk of specialised competence leaving decreases. The development strategy could in this case be to build one common platform and use configuration flags to enable or disable a feature. In this case there would be one code base for all customers. This strategy put the following constraints on the business:

* A slower pace of deliveries compared to case A: Before doing a code change a bigger architectural review of potential impact on other customers might be required. When a code change happens there is potentially more work to be done to make sure that no customer is impacted negatively.

* The business might be required to say no to some custom changes requested by a customer. If the change impacts the common software platform the cost and risk might be too high

Making the decision

Whatever is the correct decision might be in this example, it is important for the business side to sit down with the software development organisation and talk face to face. Doing this decreased the risk of the business feeling blindsided by not being able to deliver with the speed promised to the customer or being able to deliver at all. The development organisation gains confidence in that that the delivered code fits the business case. There is also a potential upside that the development organisation could realise that new code might not be the answer to full-fill a business case and thus save precious time and resources. It is not uncommon for development organisations to become code factories that doesn’t necessary deliver the intended business vale. In my experience organisations are often quite bad at getting the business and development in the same room. There is a potential for having a competitive advantage for organisations who are good at enabling this direct communication.


In conclusion, effective communication between businesspeople and developers is crucial for the success of software development projects. By working together and understanding each other’s constraints, businesses can ensure that the software they develop aligns with their goals and objectives. Developers, on the other hand, can ensure that they make technical choices that are in line with the business case.


Martin Nilsson

< Back to blog

Let's start a new project or collaborate!