What to Build for a Facility Management Business

For: Owner or COO of a UK facility management business turning £3–20M a year, running 20–150 field engineers across mixed contracts, still stitching together job cards on spreadsheets and a CAFM system that was never configured properly

If you run a UK facility management business between £3M and £20M in revenue, the software worth building custom sits in three places: a reactive job capture layer that closes the WhatsApp-to-invoice loop, an SLA evidence engine that timestamps every event a service credit clause depends on, and a subcontractor reconciliation tool that matches their invoices to your job records before your ops manager approves them. Everything else — asset registers, PPM scheduling, work order routing — buy or configure. The three above are where your margin is leaking, and they are exactly what off-the-shelf CAFM handles worst.

This post is for the owner or COO who has 20–150 engineers in the field, a CAFM system that was configured by someone who left two years ago, and a finance team that reconciles jobs to invoices in Excel on the last Friday of the month. You already know the platform vendors won't fix this. The question is what's worth building yourselves.

Start with where the money actually leaks

The UK FM market is worth around $83.3 billion in 2026, and hard services — MEP, HVAC, fire safety — make up 55.4% of it. That's the reliability-driven, SLA-heavy work where margins are thinnest and where reactive jobs pile up outside your PPM schedule. It's also where the three leaks live.

Leak 1: uncharged reactive jobs

The single biggest margin problem in mid-market FM isn't parts or labour. It's reactive work that gets done, signed off by a building manager on-site, and never invoiced because the job originated in a WhatsApp message to the engineer, a phone call to the account manager, or an email that never made it into the CAFM. The engineer fixes it, the client is happy, and three weeks later no PO exists. Your finance team never sees it.

You already know this is happening. You don't know the number. In most FM books we've looked at, it sits between 3% and 8% of reactive revenue — enough to be the difference between a profitable contract and a break-even one.

Leak 2: SLA penalty exposure you can't disprove

Most FM contracts contain service credit clauses. Industry benchmarks suggest most have never been invoked — not because vendors hit their targets, but because neither side has the timestamp evidence to prove a breach. That cuts both ways. When a client's procurement team decides to tighten up mid-contract, they'll start reading response-time logs. If your engineer's arrival time is "whenever the app synced next", you're paying credits you don't owe.

Leak 3: subcontractor invoice disputes

You use subcontractors for specialist work — lift maintenance, fire suppression, HV electrical. Their invoices arrive monthly, referencing job numbers that don't match yours, quoting hours nobody signed off, and including callouts for jobs your engineer actually attended. Scope disputes are a leading cause of FM litigation in the UK, and most of them start with undocumented verbal instructions between a site manager and a subbie's engineer.

Why your CAFM won't fix this

Only 53% of FM professionals actually use CAFM software, and 73% of organisations that chose an IWMS report lower-than-expected adoption within 12 months. The pattern is consistent: the platforms are built for the FM director's dashboard, not for the engineer standing on a plant room floor at 22:00 trying to log a job on 4G with gloves on.

Your CAFM is fine for the asset register, the PPM calendar, the compliance library (SFG20 compliance software functionality is genuinely commodity now — don't build this), and the client-facing reporting portal. What it's bad at is the messy edges: intake from non-standard channels, evidence capture that will hold up in a contract dispute, and reconciliation against third-party financial data. Those are the three places to build.

What to build, in order

Build 1: reactive job capture layer (build first)

What it is: a lightweight intake system that sits in front of your CAFM and captures every reactive job request regardless of channel — WhatsApp, email, phone, client portal, walk-up. It uses AI to parse the request, tag it against a contract, assign a job number, and push it into your CAFM as an open work order before the engineer is dispatched.

What changes: your finance team runs a single query at month-end — "jobs completed, no PO raised" — and it returns a real list instead of zero. Uncharged reactive work becomes visible. In the first three months of running one of these, most FM businesses recover somewhere between 40% and 70% of the leak.

What it takes: this is a 3–5 month build if your CAFM has a decent API (Elogbooks, Concept Evolution, MRI Evolution all do). Longer if it doesn't. The heavy lifting is the WhatsApp Business API integration, the LLM parsing layer (contract identification, priority classification, asset matching), and the audit trail. The CAFM push is the easy part.

What it's bad at: it won't stop engineers going off-book entirely. If your culture is that engineers do favours for building managers and don't tell anyone, software won't fix that. It will surface the pattern so you can manage it.

Build 2: SLA evidence engine (build second)

What it is: a passive telemetry layer that timestamps every event a service credit depends on — job logged, engineer accepted, engineer on-site (GPS-verified), first fix attempted, job closed, client sign-off. It stores the raw events in an immutable log and generates monthly SLA reports that both you and your client can trust.

What changes: two things. First, when a client challenges a response time, you have the data. Second, and more important, when you renew a contract you can price SLA tiers accurately because you know your actual performance distribution, not your CAFM's rounded averages. Reactive maintenance costs 3–5× more than preventive, and one of the reasons is that reactive SLAs are priced on guesswork.

What it takes: 2–4 months if you're already using a mobile workforce app with GPS (BigChange, Joblogic, Protean). The build is a data pipeline and a reporting UI, not a new field app. If your engineers are still on paper job sheets, do that first — but don't buy a full CAFM to solve it; buy a mobile-only tool and integrate.

What it's bad at: it creates evidence that cuts both ways. If your engineers are genuinely late a lot, you'll now know, and so might your client if they ask for the log. That's a feature, not a bug, but be ready for it.

Build 3: subcontractor reconciliation (build third)

What it is: a matching engine that ingests subcontractor invoices (PDF, CSV, portal exports), extracts line items, and matches them against your own job records — engineer attendance, sign-off times, agreed rates in the framework agreement. Discrepancies get flagged for review before anything is approved for payment.

What changes: your ops manager stops approving invoices on trust. Disputed lines get raised within days instead of at year-end reconciliation. Over 12 months, most FM businesses find that 2–5% of subcontractor spend was either duplicated, out of scope, or above the agreed rate.

What it takes: 3–4 months. The invoice parsing is now cheap thanks to modern document AI. The hard part is modelling your framework agreements — every subbie has different rate cards, callout minimums, and out-of-hours multipliers. Expect this to be genuinely bespoke.

What not to build

• PPM scheduling. Your CAFM does this. If it doesn't do it well, reconfigure it or switch — don't build.
• SFG20 compliance library. License it. SFG20 itself is the source of truth, and every serious CAFM integrates it.
• Asset register. Buy. This is commodity.
• Client reporting portal. Buy or configure inside your CAFM. Clients want familiar-looking dashboards, not something bespoke.
• Route optimisation for engineers. Unless you have 100+ engineers doing high-volume short-duration jobs, off-the-shelf beats bespoke every time.

The cost and timeline model

The three builds above are, in our experience, 8–14 months of engineering work in total if done sequentially by a small team (2–3 engineers plus a product lead). Done in parallel, 5–7 months, but you'll pay for it in change management — your ops team can only absorb so much new tooling at once.

What moves the number most:

• Your CAFM's API quality. The gap between "documented REST API" and "CSV export overnight" is roughly 2× on the reactive job build.
• How many contract types you run. A pure hard-services book is simpler than a mixed TFM + reactive + project-works book.
• How your subcontractor framework agreements are structured. Ten subbies on similar terms is a 3-month build. Fifty subbies with bespoke rate cards is 6+ months.
• Whether your engineers have smartphones you control. BYOD makes everything harder.

Illustrative example: a £12M revenue FM company, 60 engineers, one CAFM with a decent API, mixed TFM and reactive contracts, ~20 subcontractors on framework agreements. Build 1 in months 1–4, Build 2 in months 4–7, Build 3 in months 6–10. That's illustrative — your shape will differ based on the four factors above.

To turn this into a real quote you need three things: your current CAFM and its API documentation, a list of your live contracts with their SLA schedules, and a sample month of subcontractor invoices with your matching job records. Without those, any number anyone gives you is a guess. That's the conversation to have with us or anyone else you're evaluating.

How CodeNicely can help

The closest engagement in our book to what an FM business needs is Vahak, India's largest road logistics marketplace. On the surface it's a different industry, but the operational shape is the same: a field workforce (truckers, in their case) whose jobs originate across messy channels (calls, WhatsApp, brokers), whose completion has to be evidenced with timestamps and GPS, and whose payments have to be reconciled against third-party invoices at scale. We built the intake, evidence, and reconciliation layers that turned an informal market into a system with financial control. The same three layers are what an FM business needs.

We work with owners who want to keep their CAFM, own their IP, and build only the parts that are actually leaking money. If that's the shape of the conversation you want to have, our digital transformation and AI studio pages cover how we scope this kind of work.

How to sequence it

Do reactive job capture first. It pays for the rest. Once you can see uncharged jobs, you can quantify the leak, and the recovered revenue funds Build 2 and Build 3 within the first year.

Do SLA evidence second, before your next major contract renewal. Going into a renewal with 12 months of clean response-time data changes the negotiation.

Do subcontractor reconciliation third. It's the most technically involved and delivers the smallest headline number, but it's the one that compounds — because once your subbies know you check every line, the disputed lines stop appearing.

Don't try to do all three at once. Preventive-maintenance shifts alone reduce unplanned downtime by 30–50%, and adding three new systems to your ops team on top of that will collapse adoption. The 73% under-adoption number for IWMS deployments exists for a reason. Sequence carefully.

Frequently Asked Questions

Should we replace our CAFM before building anything custom?

Usually no. Most CAFM systems are fine at what they were bought for — asset registers, PPM, compliance. The problems are at the edges. Replacing the CAFM is a 12–18 month project that solves 10% of your margin leak. Building the three layers above solves 60–80% and lets you keep the CAFM. Only replace if the API is so bad that integration is genuinely impossible.

What does custom FM software actually cost to build?

The main drivers are the quality of your CAFM's API, the number and complexity of your contract types, and how bespoke your subcontractor framework agreements are. A single build (say the reactive job capture layer) is typically a 3–5 month engagement for a small team. All three layers, sequenced, is usually 8–14 months. To get a real number you need your CAFM API docs, your contract SLA schedules, and a sample of subcontractor invoices in front of the team scoping it — anything before that is a guess.

Will our engineers actually use it?

They'll use it if it makes their day faster, not if it makes yours easier. The reactive job capture layer works because it means engineers stop being chased on WhatsApp — everything goes through one channel. The SLA evidence layer works if it's passive (GPS, auto-timestamps) rather than requiring them to tap buttons. If a build requires engineers to do more admin, it will fail. Design accordingly.

How does SFG20 compliance fit into this?

SFG20 is a licensed content library, not software. Every serious CAFM software for FM companies integrates it — Concept, Elogbooks, MRI, Joblogic all do. You license SFG20 directly from BESA, and your CAFM pulls the task schedules. There is nothing to build here. If your CAFM doesn't integrate SFG20 properly, that's a configuration problem, not a custom software problem.

Can AI replace our CAFM entirely?

Not yet, and probably not usefully. What AI does well in FM right now is intake parsing (turning a WhatsApp message into a structured job), document extraction (invoices, PPM certificates, RAMS), and pattern detection (which assets fail most, which sites over-run SLAs). Those are augmentation layers on top of a CAFM, not a replacement for one. Anyone selling you an "AI-native CAFM" today is selling a rebrand.