Aadhib

Case study · Active

Building an internal CMMS around real operational workflows

The honest case for building maintenance software instead of buying it — and the conditions under which that decision is wrong.

Role
Architecture and delivery
Published
Reading time
1 min
CMMSAsset management
01

Context

Maintenance management software is a mature category with many capable products. Most organisations should buy one. The reason to build is not that the products are bad — it is that they encode a maintenance process, and sometimes that process is not yours.

02

Problem

When the software's assumptions and the organisation's workflow diverge, one of them gives. Either the process bends to the tool in ways that make people slower, or the tool gets worked around and the real system of record quietly reverts to spreadsheets while the software is still being paid for.

03

Constraints

01
Adoption decides everything
Maintenance software only works if technicians use it rather than route around it. That sets the usability bar at "faster than the workaround".
02
Assets are the spine
Work, history and responsibility all hang off the asset register. Get that model wrong and nothing above it holds together.
03
Roles differ genuinely
Requesting, assigning, performing and closing work are different jobs performed by different people in different contexts.
04
It has to demonstrate value inside a budget cycle
A platform that cannot show a change within a quarter does not get a second one.
04

Approach

I modelled the organisation's actual workflow before writing anything. I kept assets and work orders as the shared spine — those are genuinely universal — and let the routing, approvals and role behaviour follow how maintenance is really requested and closed here rather than how a vendor assumes it should be.

05

Architecture

Asset registerThe spine. Everything else references it.
Work ordersScheduled and reactive work against assets, in one history.
Role-based routingRequest, assign, perform and close as distinct steps with distinct interfaces.
06

Solution

An asset-centric maintenance system where the domain model is conventional and the workflow is specific. Scheduled and reactive work share one history per asset, so the question "what has been done to this machine" has a single answer.

When buying is the right answer

If the process is ordinary, if nobody internally will own the software long term, or if the organisation is likely to change how it works within a few years — buy. Custom internal software is a standing commitment, and the organisations that regret it are the ones that treated the build as the cost.

07

Lessons

  1. 01Build only when the process is genuinely specific and the organisation intends to keep it. Those two conditions together are rarer than they feel at the start of a project.
  2. 02Keep the domain model conventional even when the workflow is not. Assets and work orders are standard for good reasons; the customisation belongs in the routing.
  3. 03The honest adoption metric is the proportion of work that arrived through the system rather than around it. Tickets closed measures nothing.
  4. 04Custom software is a permanent commitment. The build cost is the deposit; the maintenance is the mortgage.

Stack

What it runs on

CMMSAsset management

The project

01Enterprise CMMS
OPINIONWhy internal tools deserve better UX
All case studies