Housing Technology interviewed senior executives from Aareon UK, Accent Group, MIS-AMS, Northgate Public Services and Weaver Vale Housing Trust on how, when, where and why to consider in-house software development instead of buying off-the-shelf software from external IT suppliers.
Why opt for DIY/in-house software development or external software?
Accent Group’s digital development manager, Simon Green, said, “We start with our high-level requirements and balance value, innovation, resilience, ease of use, time to ‘in-service’, integration and strategic fit. We then decide early on whether it’s possible, in terms of capability, for us to develop the product. If it is, then in-house development is judged equally against commercial off the shelf (COTS) products or partnering for development with our systems providers.
“Both in-house and external approaches work well under certain circumstances, but even when we buy an external software package or work with a partner, our in-house team brings additional value through systems integration and information management.”
Aareon UK’s managing director, Geraint Griffiths, said, “The most common reasons for going down the DIY/in-house software development route relate to the availability of COTS software to meet housing providers’ particular business requirements, the time and expense of adapting COTS software, and the desire to have complete control over the development process so there are no external dependencies.
“When opting for COTS software, then its additional benefits need to be evaluated. Typically, these will include a range of best practice functionalities which will have been tried and tested and can be evidenced across other housing customers. Furthermore, external software suppliers will have the infrastructure to support the ongoing delivery of product updates in the key areas of functionality, security and new technologies. These products normally have a range of customers of varying sizes so the software should be able to scale up and out as needed.”
Northgate Public Services’ director of housing, Trevor Hampton, said, “One of the most common reasons for opting to develop software in-house is a perception of expediency. In-house IT departments can sometimes find themselves under pressure from their boards to find an immediate fix to a problem and so in-house development seems the obvious option. The results are fast but sometimes a more holistic look at why the change needed to happen is needed.
“For example, take the race to go digital. A simple revamp of an organisation’s website by their in-house team is unlikely to be enough to deliver full access to the digital channels that tenants will expect later on. It might have been a tactical solution, but it won’t have met the strategic goals of the organisation.
“The lack of IT representation at board level is also a factor contributing to decisions to keep IT in-house. More often than not, a series of short-term, in-house fixes will fail to address a housing provider’s longer-term operational needs.”
Weaver Vale Housing Trust’s executive director of technology and business improvement, Andrew Rafferty, said, “We live and breathe our operations every day and an in-house development team has a much better understanding of our opportunities than relying on third parties. External suppliers are rarely ‘partners’; they are still suppliers who may have contradictory goals to ours.
“The advantages of in-house development include: more control because by developing a substantial in-house team, you decide your priorities and functionalities as opposed to being mandated by a third party; greater agility from more frequent, iterative developments to mirror changing tenant requirements; closer engagement because our agile approach involves colleagues at the start by creating ‘user stories’ that determine the minimum viable products (MVP); and speed of delivery, with short ‘sprints’ meaning changes can be achieved in just weeks, not months, and far faster than an external procurement process would have been completed, much less actually implemented.
“Furthermore, we can reduce our risk because non-proprietary software using a common technology stack gives us a larger pool of developers and testers to draw from, plus there’s no tie-in to the housing sector’s usual IT suppliers and their closed, proprietary systems. Finally, there’s the question of ownership and updates – in-house systems are entirely yours so you aren’t locked into third parties’ release/update cycles that you have to adhere to, even if they add little or no functional benefit, just to maintain support.”
Housing providers aren’t software developers – shouldn’t they stick to their core goals?
MIS-AMS’s software development director, Jeanette Allerston, said, “Not necessarily – all businesses are technology businesses these days, regardless of their core aims. If a housing provider can create a business case for hiring staff and prove a return on investment, then an in-house project can be made viable.
“However, significant financial investments are needed to develop a large system. The necessary resources comprise not only developers, but designers, analysts, QA professionals and project managers.”
Aareon’s Griffiths said, “While housing providers are obviously vital stakeholders in the development process, only a few have the resources to convert their principles and goals into viable systems. Careful consideration should therefore be given to long-term strategies and cost/benefit analysis before building an in-house system. Delivering functionality via an in-house team can initially seem to be rapid and bring quick benefits but the practicalities of long-term product maintenance need to be considered.”
Northgate Public Services’ Hampton said, “Housing providers already have a huge task in delivering housing without also trying to develop the software needed to achieve their goals. Technology is moving so fast these days and it’s that pace which makes it so hard for housing providers to build the knowledge, skills and insights to keep up.
“It’s also a mistake to underestimate the support needed. It might seem cheaper to develop software in-house at first, but this is a false economy when you consider the need for ongoing maintenance and development.”
Weaver Vale Housing’s Rafferty said, “Providing great products and services for internal and external customers is a core principle for any housing provider. This will be achieved more rapidly, flexibly and efficiently with a substantial in-house team than relying on (often) out-dated technology and hoping your IT supplier gives you what you want.
“To that end, we are really interested in co-developing (i.e. a true partnership of shared efforts and rewards) with other housing providers who are developing solutions to see where the synergies are. Why not collaborate at a practical, code-sharing level?”
What are the functional advantages and disadvantages?
Accent’s Green said, “When reviewing the market for a new housing management system, it was clear that the customer safety, repairs and financial asset management modules weren’t available with the functionalities we wanted without buying several different systems. So our choice was either multiple procurements or systems development and integration on top of the solid platform we already had. We opted for the latter because, in our circumstances, it was the most effective way to meet our specific requirements. And regarding any functional disadvantages to our approach, there haven’t been any so far.”
MIS-AMS’s Allerston said, “With the in-house route, you can say goodbye to a cluttered screen of functionality that you don’t want because you can tailor your software to your exact requirements.
“However, the strength of external software is that the functions are in use by thousands of other users, so they are far more stable and wider in variety. Good providers will also invest in maintenance and upgrades, and collate user feedback to inform this work. The result is that you get a good level of functionality which has been designed to help you achieve your objectives.”
Aareon’s Griffiths said, “The disadvantages of the in-house approach can be that there is no incentive to examine the process being delivered and benefiting from the sector-wide experience that is incorporated into COTS software. The in-house approach also must consider the long-term evolution of the product so that any short-term delivery decisions don’t compromise the overall ability of the product to meet long-term goals. And among other things, the disadvantages of an external approach are that the software might contain features that aren’t needed and those that are needed might not map exactly to an individual housing provider’s particular processes.”
Northgate Public Services’ Hampton said, “There are some functional advantages to developing software in-house because it will have been built to satisfy a particular organisational need, but that also makes it incredibly bespoke and often very specific to a housing provider’s requirements at a particular point in time.
“For example, in the case of service charges, every housing provider has their own formulae for recovering these charges and it can sometimes be easier to code in-house. However, in-house software is never as rich or as complete as COTS software because the latter will have been developed based on best practices within the overall housing sector. If there is then a change in policy, would an in-house solution need to be developed to meet the new requirements rather than simply reconfigured?”
What are the technical advantages and disadvantages?
Accent’s Green said, “The advantages of in-house development are clarity in terms of how the systems work, ease of integration and rapid problem resolution; if it’s not performing, it is within our gift to do something about it. But don’t neglect technical debt – spend time maintaining and documenting your own software because you’ll be the ones making any future changes.”
Aareon’s Griffiths said, “The technical advantages of in-house software are that there is a complete in-house understanding of the product and changes are only applied when necessary and don’t have to conform to suppliers’ releases and supported versions.
“The disadvantages of in-house development centre around the cost of maintenance and product management. For example, the user experience (UI/UX) needs to be maintained to match industry standards because end-users expect products to evolve in line with their other digital experiences. And while it’s not strictly a technical disadvantage, the burden of maintaining the skills and knowledge within an IT development team are significant.”
MIS-AMS’s Allerston said, “Finding the right resources to develop software in-house can be difficult because demand is outstripping supply, and if you can recruit the right team, retaining them then becomes the next challenge. With limited or inconsistent resource levels, you have a limited ability to evolve the software. And with many other competing IT priorities, it can be easy to neglect maintenance and end up with a bespoke system ‘stuck’ in an old technology for a long time.
“By contrast, external software providers are under constant pressure to remain competitive, and this incentivises them to continuously evolve their systems and use the latest technologies, so with very little in-house effort, your software always remains up-to-date.”
Weaver Vale Housing’s Rafferty said, “Having in-house capability means you have greater knowledge to take into discussions with IT suppliers about the integration capabilities of their products (where you do need to use them), rather than relying on a vague bucket of time/cost allocated for ‘integration’ in the implementation of their solution. The disadvantages are that when you start, you spend a lot of time creating the basics (such as creating APIs) and building skills.
“You will need to understand more about the business logic and processes, which is sometimes held tightly by legacy IT providers. You will also need different skillsets within your teams, but we’ve been successful in retraining colleagues who previously had MI/report-writing roles in to low-code developers via Power Apps.”
What are the financial advantages and disadvantages?
Northgate Public Services’ Hampton said, “The main financial benefit of COTS software is the transfer of risk. If an in-house project goes over budget or takes twice as long as it was meant to, then the organisation just has to swallow the impact, whereas if you have gone to a supplier, the price and specification should have been agreed and fixed from the outset.”
MIS-AMS’s Allerston said, “Buying external software can be much cheaper than in-house development because the package is already available off the shelf and the development costs are shared across the provider’s customer base.
“Granted, you can lose some of the control you would have if developing in-house, but a good compromise which achieves the best of both worlds is to buy a core business system and then augment it in-house to get exactly what you want at a lower cost and with less risk.”
Weaver Vale Housing’s Rafferty said, “In-house development is definitely cheaper. With daily rates of around £1,000 per person per day, lead times (and therefore ‘time to solution’) measured in months and annual support costs of 20 per cent, not to mention lengthy procurement processes and (often) eye-watering licence costs, it’s very easy to make the numbers add up for in-house development.
“Choosing widely available development platforms means you have a huge pool of relatively inexpensive contract resource available to supplement the team if you need to, unlike the restricted pool of vendor (or their select partner) resources that are available for proprietary solutions.
“There are very few disadvantages. Yes, you’ll need to keep your in-house team’s skills up to date, but there is a lot of free material for common technical tools and techniques and you’ll want to retain good staff, but that’s the same for any function.”
Can housing providers really manage typical software lifecycles?
Aareon’s Griffiths said, “Housing providers’ IT departments are usually set up to manage hardware infrastructure, deliver backup policies, support end-users and provide first-line support. They may also provide services such as report writing and management of the implementation of new software packages.
“However, in order to manage a product that supports the business then the software development cycle needs to be managed in its entirety from requirements identification, development and testing through to rollout, training and ongoing maintenance releases. This is an iterative process that continues for the life of the product and is important to ensure the product incorporates feedback, adds new features and continues to deliver value. This is an obvious financial disadvantage of the in-house delivery model, particularly if the cost exceeds the typical ‘software licence plus maintenance’ model.”
Accent’s Green said, “Product management is a universal challenge so you just have to get on with it, whether that’s in-house or via a third party. Whatever you develop or buy will rely on something else to function or will need some maintenance. So lifecycle management applies to both approaches. It does require more discipline and planning internally, whereas using third-party hosted systems you have less choice and perhaps need less discipline because at some point the system will be upgraded for you, whether you’re ready or not.”
Northgate Public Services’ Hampton said, “It is too much to expect a housing provider to deliver and maintain the number of systems they typically need, making it hard for them to respond and build software fast enough to solve and support immediate or strategic needs.
“Another reason is the cloud. The move to the cloud has been driven by the demand for anytime, anywhere access for staff and tenants. But it’s not easy for housing providers to build solutions that can be openly integrated onto other cloud infrastructures, making them vulnerable to potential loss of service. Rather than attempt to do so and risk being unable to connect all their systems, housing providers should look for external suppliers who should provide an open system at no extra cost.”
Weaver Vale Housing’s Rafferty said, “Housing providers shouldn’t be following typical software lifecycles; iterative development using agile methods does away with that thinking. Once the MVP is live, engaged users become part of the solution and have to build a (brief) business case for change. Change isn’t delivered to them; they co-create it.
“Our digital solution development unit is a business function like any other. It’s just a way of delivering solutions so you have to have the right people on board and allow them to put in the practices and processes that will allow them to deliver the solutions that the organisation needs. It is a collaborative process so expect to be more involved than you would otherwise be, but also expect to end up with what you need and not to have to make your needs fit around what a vendor has on offer.”
Any heuristics to determine whether to opt for in-house or external software?
Weaver Vale Housing’s Rafferty said, “If there is an existing product which is open, interoperable, fairly-priced and fulfils a niche requirement, then we would still be likely to buy it. However, we are looking more at toolkits than fixed solutions because we don’t necessarily know what we will be concentrating on in the next 6-18 months.
“It is important that there is commitment, trust and openness for agile ways of working. The change is cultural, moving IT from a support role to becoming a key business enabler. The organisation has to be behind that move if you’re going to succeed. If you try and fit this into the traditional control-based practices which are prevalent in a highly regulated sector, you’ll end up with a fraction of the potential value.”
Accent’s Green said, “You must bring together a multi-disciplinary team and be realistic about development timescales and exact-fit functionality vs. buy and configure. Make the decision, pause, and reflect before committing to the decision, but once committed, give it 100 per cent.”
Housing Technology would like to thank Geraint Griffiths (Aareon UK), Simon Green (Accent Group), Jeanette Allerston (MIS-AMS), Trevor Hampton (Northgate Public Services) and Andrew Rafferty (Weaver Vale Housing Trust) for their editorial contributions to this article.
