The Home CMMS Journey: Why I Gave Up on Apps and Built My Own
A few months ago I wrote about why a home CMMS might not be as ridiculous as it sounds. The short version: too many things to maintain, too many dates to remember, and a professional background that made “just winging it” feel increasingly irresponsible.
This is the follow-up I promised — what happened when I actually went looking for a tool.
The Third-Party Search
I started where most people would: looking for something ready-made. The market for home CMMS software sits in an odd gap. Enterprise systems like IBM Maximo and openMAINT exist, but they’re built for teams of engineers managing hundreds of buildings. Installing one for your own house is like buying a forklift to move the bins out.
At the consumer end, most apps are either glorified to-do lists with a ‘maintenance’ coat of paint, or they’re SaaS platforms that want a hefty monthly subscription for the privilege of reminding you to bleed the radiators, the “Free” offerings a crippled in someway making the CMMS just good enough, but ensuring you will pay in the long run to get the functionality needed.
I gave SuperCMMS a fair go. It’s clean, modern, and clearly built by people who understand maintenance and tbh I really liked it. I set up Plas Gwernoer as a location, added sub-locations for the house, workshop, barn, and vehicles, and started creating work orders. It works. For a lot of people, it would be the right answer.
But four things nagged at me.
Firstly. My data was sitting on someone else’s server, who know where, and potentially being mined by who knows who. For a property in a quiet corner of North Wales with spotty internet, I wanted something that worked whether the broadband was behaving or not. Secondly Secondly, the structure was fixed and I couldn’t tweak anything to my liking. This is partly due to decades of working with Maximo but it also meant getting backups of my data was nearly impossible without a lot of fuss. I was constantly having to work around the app’s assumptions. At number three, The promise of SuperCMMS releasing the code in GIT has never happened or ever seemed likely to happen, Lastly, and this is the honest one: I wanted to build something.
Going Self-Hosted
I’d been tinkering with Python for other projects, and FastAPI kept coming up as a framework that could serve web pages without the overhead of something like Django. So I opened a blank file and started typing.
The first version was about 300 lines of Python in a single file. One SQLite database, a handful of HTML templates, and a lot of optimism. It could list locations, create assets, and track work orders. It looked like a spreadsheet had an argument with a website and neither won.
But it worked! On my network. With my data. And when I wanted to change how priorities sorted, I changed four lines and restarted the server.
What It Became
Over a couple of weeks — mostly evenings after work and a few weekend sessions — the project grew into something surprisingly capable:
- Hierarchical locations — Plas Gwernoer sits at the top, with the house, workshop, barn, farm, and vehicles underneath. Each with their own sub-locations.
- Asset tracking — every piece of equipment tied to a location, with categories, manufacturers, warranty dates, and CSV bulk import.
- Work orders — full status workflow from Open through to Done complete with a queued status for those I in the icebox, priority levels, due dates, audit history, and filtering.
- Multi-user authentication — session-based login with bcrypt-hashed passwords. My other half can log in from her laptop and see what needs doing without me having to explain my filing system (not ever likely, but possible).
- HTTPS on the LAN — proper TLS certificates so browsers stop complaining about insecure connections.
The codebase went from a single 1,200-line Python file to a properly structured project with separate route modules, shared helpers, and a README that would make sense to someone who isn’t me. It lives in a private GitHub repository and deploys to an always-on iMac via git pull.
The tech stack is deliberately boring: Python, FastAPI, SQLite, Jinja2 templates, and plain CSS. No JavaScript frameworks, no build tools, no Docker containers. You clone the repo, install four pip packages, and run one command. If it breaks, there are about seven files to look at.
What I Learned
Building your own tool when perfectly good ones exist is not very efficient. I could have been using SuperCMMS productively from day one instead of spending evenings debugging middleware ordering and fighting with my text editor’s autoformatter, looking at you Zed.
But efficiency wasn’t the point. I now understand how every part of the system works because I wrote it. When I wanted work order history with an audit trail, I added a table and a template. When the priority sorting was wrong, I fixed a SQL query. When the browser moaned about HTTP, I learned about mkcert and TLS certificates.
The system currently tracks around 100 assets across six locations, with work orders for everything from boiler servicing to drone firmware updates. The next step is planned maintenance — scheduled recurring tasks that auto-generate work orders when they’re due. That’s the real value of a CMMS, and the database schema is already waiting for it.
Would I Recommend This?
If you want a working home CMMS today: use SuperCMMS or one of the other SaaS options. They’re built by people who do this professionally and they’ll save you a lot of evenings.
If you want to learn Python, understand web applications, and have a project that’s genuinely useful when it’s finished: build your own. Just disable your text editor’s HTML autoformatter first.
Trust me on that one ;-).