To fully understand the pros and cons of building in-house versus commercial off-the-shelf (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 rent accounting. Our customers were mainly newly-formed housing providers that had recently gone through the large-scale voluntary transfer (LSVT) process, and for the first time needed their own IT systems because they could no longer rely on using systems provided by their former 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 we never managed to sell it to anyone else. It’s just as well that FoI requests weren’t around at the time, bearing in mind how much public money was spent on it.
No more bespoke development
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 on 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 again 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. We had previously 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, let’s chat over a beer…).
We needed to differentiate ourselves so we 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 their 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 increasingly impressive but very complicated customer solutions.
After a few years, some of our earlier adopters began 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), but 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 housing management systems from scratch. In most cases, they were never fully able to untangle themselves from their legacy vendor, and most are still using those old systems to this day.
Stop making sense
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 an article for Housing Technology (‘Suits you, sir’, July 2014) about how 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 and/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. I’d suggest that a risk-balanced profile for a housing provider is probably something like 70 per cent core, 20 per cent configuration and 10 per cent customisation.
In my experience, implementations tend to involve much more configuration, in the form of dozens (or even 100s) of lists of codes and parameters, because of this vicious circle:
- Every organisation 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.
Fraught with risk
Consequently, 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 deciding what to build with them. This is why at Esuasive, we built a modular platform of ready-made components which enable housing providers to innovate at pace and build customisations only where the risk/reward is justified. The beauty of working with Microsoft is it can build and support software infrastructures that sector-specific vendors can only dream of, and all stuff I wish I’d had 20 years ago!
Aidan Dunphy is the chief product officer at Esuasive.
