Are you an FM company, or a software company?

The pitch is always reasonable.

"We know our processes better than any vendor. We can build exactly what we need. We avoid licence fees. We own the IP. We control the roadmap."

Every word of that is true. None of it survives contact with the actual cost of building back-office software in 2026. This is the long version of the conversation that should have happened before the board approved the budget.

Question one: where is your moat?

You are an FM company. Your competitive moat is some mix of: engineer relationships, sub-contractor network depth, compliance discipline, client trust built over years, and cost-to-deliver per work order.

It is not the back-office software. The back-office software is what keeps the moat from leaking. It is plumbing. The buying decision should be the same one you make about your CAFM, your accounting system, your payroll: does it work, does it integrate, does it not embarrass us in front of clients.

The first question on any "should we build it?" board paper is: does this software, once built, generate revenue, or does it support revenue? If it supports, you do not build. You buy.

Question two: do you know what enterprise software actually costs to build?

The numbers below are well documented and not specific to FM. They are the baseline reality of building any moderately complex internal platform in 2026.

Standish Group CHAOS Report

Across 50,000+ tracked enterprise software projects:

That is roughly a one-in-three chance your build reaches production close to the original spec. The other two outcomes both end with you still needing the back-office to function.

McKinsey, on large IT projects

Large IT initiatives average 45% over budget, 7% over time, and deliver 56% less business value than projected. For a £1.5m, 18-month plan that is roughly £680k of overspend and a system doing about half of what you signed up for.

Gartner, on the operations split

In a steady-state enterprise IT shop, 60 to 70% of the budget goes to maintenance and operations, not new features. Once your in-house platform is built, two-thirds of every engineering pound from then on is keeping the lights on.

Stack Overflow developer survey

Average software engineer tenure at a single employer: around 2.4 years. The senior engineer who designed your platform is statistically likely to leave within three years. The institutional knowledge leaves with them.

Question three: who, exactly, is going to build it?

A back-office automation platform for an FM operation needs, at a minimum:

2 senior backend engineers (the integrations, the data model, the queueing layer). 1 senior infra / DevOps engineer (uptime, CI/CD, secrets, audit logging). 1 to 2 frontend engineers (admin tooling, dashboards, client-facing surfaces). 1 QA. 1 product manager who actually understands FM. 1 designer (you can share with marketing).

UK loaded 2026 senior engineer cost: roughly £130k to £170k all-in. Loaded senior infra: same. Frontend: £110k to £140k. PM: £100k to £130k. QA: £90k to £110k. Designer: £80k to £110k.

You will also have to recruit them. Senior engineers with both back-office automation experience and an interest in FM as a domain are rare. The good ones have a half-dozen offers. They will not stay if the product is not their main career story.

Question four: who handles integrations, forever?

This is the line item that sinks more in-house builds than any other.

A working FM back-office talks to:

   YOUR IN-HOUSE PLATFORM
            │
   ┌────────┴────────┬─────────────┬──────────────┬────────────┐
   │                 │             │              │            │
   ▼                 ▼             ▼              ▼            ▼
  CAFM             ACCOUNTS      EMAIL          IDENTITY     CLIENT
  (4-6 of)         (Xero/Sage/   (M365 /        (Azure AD /  PORTALS
  Infraspeak       QuickBooks/   Google)        Okta)        (one per
  SimPRO           NetSuite/                                  major
  Job Logic        D365)                                      client)
  Unifocus
  Invida           ── breaking changes per integration ──
  Fergus              2 - 4 dev-months / yr / integration
                      every year, forever

Every one of those is a moving target. Infraspeak ships breaking API changes a few times a year. Xero deprecates auth flows. SimPRO renames fields. Microsoft retires Graph endpoints. Each integration is a 2 to 4 dev-month commitment to maintain, every year. That is before you add a new client whose portal has its own SOAP-with-WS-Security flavour.

Three integrations live, three breaking changes per year per integration: roughly 18 to 36 dev-months of pure maintenance work, against a team that fits in a single Slack channel. Maintenance crowds out features. Features your business is paying you to build.

This is what the 60 to 70% maintenance ratio looks like in practice.

Question five: what happens when the lead developer leaves?

The CHAOS data assumes a stable team. Yours will not be.

The senior engineer who designed the message bus, the field-extraction prompt, the supplier-resolution heuristic, the invoice-coding rules: that person will leave. Not "if". When. Stack Overflow's tenure data says about 30% of your team turns over per year on average. If they leave before the documentation gets written (which in steady-state internal software is most of the time), you inherit a system nobody fully understands and cannot safely change.

The standard pattern: the platform freezes. New requests get a "we'll look at it next quarter" answer. The COO loses patience. Six months later the conversation is "should we look at a vendor?"

This is the most expensive way to find out you should have bought.

Question six: what would you not do internally?

You did not build your CAFM. You did not build your phone system. You did not build your accounting package. You did not build your payroll software. You did not build your CRM.

You bought all of them, because the right answer for any non-core back-office system is the one that already works on day one, that has a vendor on the hook for the integration breaks, that has 200 other customers stress-testing it before you do.

The same logic applies to back-office automation. Probably more so, because the rate of change in AI tooling in 2026 is faster than any internal team can match. The model that backs your document extraction got 30% better last quarter. Did your in-house build pick that up automatically?

The real question

Are you an FM company, or a software company?

If you are an FM company, your engineers (if you have any) should be on the things your clients pay for directly: ops dashboards, commercial tooling, the client-facing portal that closes the next contract. Not the seventeenth integration with a CAFM vendor's REST API that you do not control.

If you are a software company, you would not be reading this. You would already have a 30-engineer team and you would still be losing the engineers to vendors who pay them more.

Buy vs build, the heuristic for FM

The honest summary

Most FM companies are not software companies. They should not pretend to be. Pretending costs roughly £1.5m to £2m and 18 months, with a coin-flip chance of working.

The best FM operations in 2026 are the ones that make a clean choice: keep engineering and product effort on the things that earn revenue (commercial, ops, client-facing), and let a vendor own the back-office.

The savings on day one are smaller than the build pitch claims. The savings over five years are not even close.