What if your clients all wanted the same software?

May 16, 2023

What if your clients all wanted the same software? How fast would you grow then?

How software customization can hold you back and what to do about it.

Part 1: Why bespoke software customization should be a thing of the past

If you produce enterprise solutions, you know that any enterprise organization will have at least some demands for bespoke development. This is usually in one or more of the following areas:

  • The implementation of their own styling/branding. This can be arranged with a good content management component and a configurable style sheet section.
  • Personalized jargon / bespoke entry fields. Every company has its own terminology and often wants to enter custom fields. It is not so much the field itself that presents the challenge as the need to have that custom field interact with the rest of your application.
  • Integrations. The ecosystem in which your application operates always has a few usual suspects you can build a business case around. But in particular, in the more modern, granular architectures, some integrations only occur once or twice. If an API is available, this makes the integration easier. But integrations can lead to a Mexican standoff between two suppliers, who both believe the other party should integrate on their API.
  • Bespoke decision ruling. Enterprise organizations have their own processes, decision rulings, calculations, and ways of meeting compliance. Depending on the complexity of the decision rules, this can be a time-consuming task involving much liability.

 

Benefits and downside of bespoke development

The bespoke work for clients has both advantages and disadvantages: the benefit is that the initial revenues can increase. It is possible to agree to perform custom work on an hourly fee, leading to a very profitable project. If maintenance of the bespoke work is part of the contract, it could even be recurring revenue. However, there are three ways to deal with these types of projects:

OPTION 1: Hire a flexible external team or business partner to perform the bespoke work. In that case, you risk the ‘Frankenstein phenomenon’: non-uniform ways to approach specific code challenges. Maintaining the bespoke development soon becomes a specialist job only a few can do.

OPTION 2: Staff in-house to have an in-company team on bespoke delivery. Doing so poses a financial risk because the team constantly needs to be on a project to avoid draining the company financially. That continuity might not be there.

OPTION 3: Perform these projects using your regular development staff. This choice has less risk but drastically slows down your generic development. Still, this is what we see happening most in organizations.

Place of bespoke deveopment in the organization visualized: an external partner, a bespoke team or part of the core team activities

And, of course, there is always the fourth option of denying your client bespoke work and referring to the generic roadmap. 

The biggest downside to these bespoke projects is that the revenue is based on working hours, which is not scaleable. An increase in clients directly results in more services you must perform, thus, more employees you need to hire. And as we know, good employees are very hard to come by. 

But even more important: if you should decide to pull staff from your permanent team, you slow down your generic development considerably. Even worse, when the bespoke work requires maintenance, it clogs your generic work. 

And lastly, bespoke work poses a potential liability challenge. It is tough to manage expectations when it comes to custom development. And even when you manage this, it is challenging for the client to test the system’s functionality, particularly when things are hard-coded into the application. Once mistakes, misinterpretations, or miscommunications are discovered, the question arises of who is liable for the consequences. 

Option 1 seems to be the most attractive from this perspective. Suppose you place your bespoke work outside your organization; you could limit the accompanying vulnerabilities. Yet you risk the customer experience being compromised. 

Stay tuned for part II of this article, which discusses the 5 levels of business rule maturity. Make sure you don’t miss it, and follow Rulecube on LinkedIn

Read more