By Aidan Dunphy, Chief Product Officer, Esuasive
To fully understand the pros and cons of building in-house versus COTS software, you need to have been around for a while, so please bear with me while I tell you a story…
I started out in 1997 as a software engineer for one of the top housing management system vendors, specialising in the Rent Accounting area. Our customers were mainly newly-formed housing associations that had recently undergone the Large Scale Voluntary Transfer (LSVT) process, and for the first time needed their own IT systems as they could no longer rely on using systems provided by their former parent Local Authority. We were good at this, and our product became one of the most successful packaged systems on the market.
Our product had previously been customised to suit individual customers. An extreme example was a carve-up of our Rents module to enable our largest customer to separate data and process for their five divisions. This was a critical requirement during the sales negotiation and took years to complete, but as far as I know it was never actually used - and it goes without saying that we never managed to sell it to anyone else. It’s just as well that FOI wasn’t around at the time, bearing in mind how much public money was spent on it.
At the all-hands meeting that year, our MD announced a strategic directive: “NO MORE BESPOKE!” Henceforth, we were to resist pressure from prospective or existing customers to create one-off functionality. Instead, we were to impress upon them the benefit of adopting a standardised, supportable solution built using the collective experience of many previous customers. Although we did write bespoke interfaces, never more did we change our core product at the behest of a single customer.
By 2002 the market was saturated, and there was little to choose between the leading housing systems. In the past we had competed on functionality, but everyone else had caught up. Moreover, the more features you add to a product, the harder it becomes to make changes. Seemingly trivial modifications require a huge amount of analysis to ensure they won’t create bugs elsewhere. You see this in every big software product; It’s an inevitable consequence of continued development (if you’re thinking “microservices” at this point, we can chat over a beer).
We needed to differentiate, so embarked on a major project to incorporate CRM, forms design and workflow into our product, rendering the (by now, huge) HMS functionality via an internal API. The idea was that customers could customise flows, forms and even database fields without compromising the integrity of the supported product. We expected customers would focus mainly on screen sequencing, task allocation and minor form alterations.
How wrong we were
The new product was extremely popular for several years, due largely to the dazzling possibilities it offered. Nevertheless, no matter how much sophistication we built into the toolkit, customers always wanted more. Over time, what was supposed to be a ‘no-code’ platform evolved into a full-featured development platform. We even had a specialised team who used our toolkit to build ever more impressive but very complex customer solutions.
After a few years, some of our earlier adopters started to abandon the toolkit. Having built more and more bespoke solutions, they were finding it increasingly difficult to support them. We could fix something they’d made (undocumented, of course) only at consultancy rates, or they could engage an independent consultant. Either way it was expensive, and an alternative approach had appeared: Microsoft Dynamics had come of age, offering a low/no-code toolkit promising unparalleled integration with their main business technology platform - and you didn’t need software engineers!
Wind forward a few years, and once again we saw horror stories of adventurous organisations spending megabucks in vain attempts to build a housing management system from scratch. In most cases they were never fully able to disentangle themselves from their legacy vendor, and most are still using those old HMS systems to this day.
Why does this happen?
I believe it’s not the platform, it’s what you’re trying to build with it. A decade ago, I wrote in an article in Housing Technology (“Suit You, Sir”) that Housing Providers can’t economically write all of their own software, and the latest generation of low-code platforms hasn’t changed my mind. It just doesn’t make sense to take on the cost and risk of developing and supporting processes that are the same across the sector, and for which there is no competition motive.
Selling a standardised product in any B2B market is tricky, and Housing is no different. Each buyer genuinely has unique requirements due to their geography, business model or culture. Unfortunately it’s difficult for the buyer to be strategic about customisation risk. They find themselves in a position of power, waving their budget like a juicy steak at a slavering pack of hungry vendors, who compete to tick as many “Compliant” boxes as possible. “That’s a silly requirement” doesn’t score well in an ITT assessment.
To navigate this situation, I use the Core, Configuration and Customisation model for requirements:
Core, Configuration and Customisation
Risk-Reward
I’d suggest that a risk-balanced profile for a Housing Provider is probably something like 70% core, 20% configuration, 10% customisation. In my experience implementations tend to involve much more configuration, in the form of dozens (or even hundreds) of lists of codes and parameters, because of this vicious circle:
- Every org invents their own codification, because there are no standards.
- When procuring a system, they prefer those that don’t require them to change, so vendors make them highly configurable.
- No industry standards arise because buyers don’t need to change and vendors have to do what sells.
So the sector’s business system landscape is fraught with risk. Microsoft’s Dynamics and Power Platforms are hugely powerful, but it’s crucial to be strategic when choosing what to build with them. This is why at Esuasive we built a modular platform of ready-made components which enable Providers to innovate at pace, and build customisations only where the risk-reward is justified. The beauty of working with Microsoft is they can build and support software infrastructure that sector-specific vendors can but dream of - stuff I wish I’d had twenty years ago!