West Midlands Fire Service Ditches In-House Build for SaaS

Every engineering org eventually inherits a building it didn't design: a creaking in-house system that started as a clever shortcut and ended up as load-bearing infrastructure nobody wants to touch. West Midlands Fire Service has just decided to demolish theirs and move into a serviced apartment instead. For anyone running a public-sector platform, or any platform with a ten-year-old custom CRM in the basement, this one is worth reading carefully.

The headline is small. The signal is not. A large UK fire and rescue service has chosen a commercial off-the-shelf SaaS over the codebase its own team built and maintained for years. That's the building being condemned, and the relocation is what the rest of this piece is about.

The Problem

WMFS is not a small operation. As International Fire & Safety Journal reported, the Service runs more than 20,000 Safe and Well Visits each year and delivers safety education to over 30,000 children. That's a serious volume of scheduling, risk capture, follow-up, and outcome reporting, all of it happening in people's living rooms and school halls rather than at a desk.

The in-house system that grew up around that workload almost certainly did its job for a long time. Bespoke internal tools usually do, until they don't. The failure mode is rarely a dramatic outage. It's the slow tax: every new questionnaire requires a developer, every device upgrade breaks the offline sync, every audit cycle exposes another field that nobody can quite explain. Anyone who has tried to add a single column to a decade-old internal CRM knows the meeting that follows.

Emily Fernandez, Assistant Director for Prevention at WMFS, framed the move as streamlining processes and giving teams better tools. Read between the lines and you can see the constraints that have changed. Mobile-first is now table stakes for any field workforce. Offline-tolerant data capture is an expectation, not a feature request. Integration with Microsoft 365, SharePoint, and identity tooling like Entra ID is increasingly the default substrate of UK public sector IT, and a bespoke .NET app from 2014 was probably never going to catch up gracefully.

There's also a quieter pressure: demonstrating outcomes. Prevention work has always been hard to measure, and modern commissioning expects evidence. If your data model can't track an individual risk profile through to a measurable intervention outcome, you're going to lose that argument every budget cycle. The in-house system, in all likelihood, was built to record activity, not to prove impact. That's a different schema entirely, and retrofitting it is the part where it all falls over.

Options on the Table

Whenever a public body sits down to replace a long-lived internal system, three doors are usually open. WMFS picked door number two, but the other two are worth walking through because most readers of this site will face the same choice in a different vertical.

Door one: rebuild in-house, modern stack. Take the existing domain knowledge, throw it onto Azure or AWS, slap a React Native client on the front, and call it a day. Tempting, especially when you have a team that already understands the workflow. The trap is the one every CTO eventually learns: the first 80% takes a year, the last 20% takes five, and by the time you ship the camera-upload feature your phones have moved two OS generations. For a fire service, where the core mission isn't writing software, this is almost always a bad bet.

Door two: commercial off-the-shelf, vertical-specific. This is what WMFS chose. LearnPro Group's Prevent + Protect is built specifically for fire and rescue services, runs on Microsoft Azure, and integrates with Microsoft 365 services including SharePoint Online and Entra ID. It uses no-code configuration so the Service itself can shape job types, questionnaires, and scoring without raising a Jira ticket. Russell Wood, LearnPro's UKFRS Market Lead, called WMFS "one of the largest and most innovative Services in the country," which is the kind of quote you read past, but it matters: vertical SaaS lives or dies on its reference customers.

Door three: horizontal platform plus heavy customisation. Take a Salesforce or a Dynamics 365, build the prevention workflows on top, integrate with everything else. This is the option that always looks great in the procurement deck and usually ends up costing more than door one. The horizontal CRMs are powerful, but the gap between "supports custom objects" and "knows what a Safe and Well Visit is" is paid for in consultant day rates. For a workflow as domain-specific as community fire prevention, you're essentially funding the vendor to build vertical SaaS for you, badly.

The trade-off matrix here isn't subtle. Door one gives you control and a maintenance bill forever. Door three gives you a familiar platform and a consultancy dependency. Door two gives you speed and a vendor lock-in problem. WMFS clearly decided the lock-in is the lesser evil, and I'd argue they're right, provided the contract has its data-portability teeth in.

What Engineering Teams Should Actually Do

If you're a platform lead watching this from an iGaming, fintech, or ad-tech seat, the lesson generalises. The question isn't whether to build or buy in the abstract. It's whether the workflow you're automating is your competitive edge or your operational plumbing.

Prevention activity tracking is plumbing for a fire service. Their edge is the firefighters, the community relationships, the operational judgement. Software that records who visited which house, what risks were flagged, and whether the SMS follow-up got a response is plumbing. Plumbing should be bought, not built, unless you can articulate a specific reason your plumbing needs to be different from everyone else's.

The practical playbook: start by writing down, honestly, what your in-house system does that a vertical SaaS couldn't. If the answer is "it integrates with our weird identity setup" or "it has fields nobody uses anymore," you have your answer. If the answer is "it embodies five years of tuning that directly affects our core KPIs," keep building.

Second, when you do go to market, weight the architectural fundamentals heavily. Cloud-native and mobile-first are not marketing words in this context. They're the difference between a system that survives the next five years of device and OS churn and one that needs a rewrite in three. The Prevent + Protect platform's offline capabilities, route planning, and camera/file upload support are exactly the boring-but-essential features that an in-house team would deprioritise for years.

Third, push hard on no-code configuration. The single biggest reason in-house systems get built is that the commercial alternatives required a developer to change a dropdown. Modern vertical SaaS has largely solved this. If a vendor can't show you a non-developer changing a workflow live in the demo, walk away.

Gotchas and Edge Cases

The shine on a procurement decision wears off the day implementation starts. A few things to watch when you make the same kind of move.

Data migration from a long-standing in-house system is almost always worse than estimated. Bespoke databases accumulate undocumented semantics: a status code that means one thing in records before 2019 and something else after, a free-text field that some teams used as a structured tag. Budget for a forensic data archaeology phase, not a straight ETL.

The Microsoft 365 integration story sounds tidy on a slide. SharePoint Online and Entra ID are well-trodden ground, but the guts of it, permission inheritance, guest access, conditional access policies, can turn a two-week integration into a two-quarter one. Get your identity team in the room before contract signature, not after.

SMS feedback loops with URL links to tailored questionnaires are clever, and they're also a phishing-training nightmare waiting to happen. The same mechanism that lets WMFS measure intervention effectiveness looks identical to the smishing patterns every security team is training citizens to ignore. Domain choice, link branding, and message framing matter here more than the engineering does.

Finally, the no-code configuration freedom is a double-edged sword. Give every team the ability to spin up new job types and questionnaires, and within eighteen months you have a configuration sprawl problem that mirrors the schema sprawl of the system you just retired. Governance has to be designed in from day one.

Key Takeaways

• WMFS replacing its in-house prevention software with LearnPro's Prevent + Protect is a clean example of a public body deciding that operational plumbing belongs in vertical SaaS, not in a bespoke codebase.
• Cloud-native and mobile-first architecture, with offline capabilities and Microsoft 365 integration via SharePoint Online and Entra ID, is now the realistic baseline for any field-workforce platform.
• No-code configuration for job types, questionnaires, and scoring is the feature that historically pushed organisations to build in-house. Modern vertical SaaS has largely closed that gap, and it should be a non-negotiable in any RFP.
• Data migration, identity integration, and SMS-based feedback patterns are the three places implementations most commonly slip. Plan for them explicitly rather than discovering them.
• The build-versus-buy decision is really a question about whether the workflow is your edge or your plumbing. WMFS answered it correctly. Most engineering teams in regulated verticals should be asking the same question this quarter.

Back to the building we started with. WMFS hasn't just moved out of the creaking house, they've signed a lease on a serviced apartment with the bins taken out and the wifi already working. The trade is autonomy for velocity, and for a service whose actual mission is keeping people safe rather than maintaining schedulers, that's the right trade. The rest of us, sat on our own ageing internal tools, should at least walk past the new building and take notes.