Use case
Cmms Maintenance Management Software
A CMMS is only as good as the completion data technicians type into it, which is why so many of them end up as an asset list nobody trusts and a PM calendar nobody closes.
CMMS stands for Computerized Maintenance Management System. It tracks the equipment you own, the work done on it, and the maintenance that is due, so that repairs stop being a thing somebody remembers and start being a thing the system schedules. Buying cmms maintenance management software is the usual answer, and for most maintenance teams it is still the right one.
Two things before the rest of this page is useful. We sell source code you clone and run yourself, so there is no signup here and no hosted maintenance product. And most people searching this term should install something that already exists rather than build one, because the boring parts of a CMMS are numerous and none of them are where your plant is different from anyone else's.
The rest of this page covers what the category actually contains, why the free options are worth a serious look, and the narrow case where building is defensible.
What a CMMS is made of
The demos lead with the work order screen. The parts that decide whether the system survives contact with a maintenance team are underneath it.
Five systems under the work order
- An asset hierarchy, not an asset listSite, area, system, asset, component. The hierarchy is what lets you ask whether the failures are concentrated in one line or one pump model. A flat list of equipment cannot answer that question, and re-parenting a flat list later means revisiting every historical work order.
- Work orders in more than one flavourCorrective work reacts to a failure, preventive work runs on a schedule, and condition-based work triggers off a reading. They share a table and diverge in how they are created, so the trigger belongs on its own model rather than as a nullable column.
- PM schedules with two kinds of triggerCalendar triggers are easy: every 90 days. Meter triggers are the hard ones: every 250 running hours, which requires meter readings to arrive from somewhere and a rule for what happens when three intervals elapse before anyone reads the meter.
- Spare parts that a work order consumesClosing a work order should decrement the parts it used, in the same transaction that closes it. This is the seam where a CMMS turns into inventory software, and it is where teams who bought two separate products discover they now reconcile by hand.
- History that survives the assetWhen a pump is replaced, the work order history belongs to the position in the hierarchy as much as to the serial number, or the reliability data resets every time maintenance does its job.
None of these are unique to your plant, which is the strongest argument for buying rather than building.
Try the free options properly before costing a build
The search results for this category are dominated by vendor listicles, so the free end of it is worth stating plainly.
How many sites and what triggers your PMs?
A spreadsheet may genuinely be enough.
- A dated PM list with a completion column answers most of what a small team needs from a CMMS
- It fails at meter-based triggers, concurrent editing, and any question about failure history
- The moment two people edit it at once, or somebody asks which asset fails most, it has stopped being enough
An existing CMMS, free tier or open source.
- Odoo ships a maintenance module, and openMAINT is a purpose-built open source asset and maintenance manager
- Several commercial products have free tiers that carry a single site well past the point a spreadsheet gives up
- These are other people's software, not ours, and their licences and hosting bills are their own
Cost the migration, not the licence. Getting an asset hierarchy and two years of work order history out of a product you outgrow is the expensive part.
The one thing worth checking before committing to any of them is the export. Ask what an asset hierarchy and a completed work order look like on the way out, in a format you could load somewhere else. A CMMS accumulates the only record of what has been done to your equipment, and that record is worth more than the software holding it.
The failure mode is data entry, not features
Maintenance systems rarely fail because the software lacked a feature. They fail because the completion data stopped arriving, and once a few months of history is missing, the reports built on it are guesses with a chart around them.
The mechanism is usually physical. Technicians work in plant rooms, basements, and roof spaces, which is exactly where mobile signal is worst, and a form that will not submit gets filled in later from memory, or not at all. Any evaluation of a CMMS should include one technician, one phone, and the worst-connected asset on the site.
This matters for the build decision more than any feature comparison. Offline capture is not a checkbox, it is a sync queue, a conflict rule for two people closing the same work order, and a story for what happens when a phone comes back online a week later. It is one of the larger pieces of engineering in the whole category, and it is the piece a web application does not get for free.
When building is defensible
Building a CMMS from nothing is usually a bad trade. There is a narrower version that is not.
Maintenance is the product you sell
A contractor maintaining equipment for other people needs multi-tenant customer accounts, per-customer asset registers, and billing. That is a maintenance SaaS, not an internal CMMS, and the products in this category are mostly built for the internal case.
The asset is unusual enough to break the model
Equipment that moves between sites, is owned by a customer, or is a fleet of identical units tracked by serial number tends to fight a fixed asset hierarchy. If every vendor demo needs you to rename core fields, reporting will be affected too.
It has to live inside something you already run
If work orders need to sit next to the customer records and invoices in an existing internal application, a second product with a second login is a real cost.
What does not justify it: a vendor interface you dislike, one missing report, or a licence cost you have not compared against the salary cost of maintaining your own.
What you would start from here
There is no CMMS in this stack. No asset model, no work order table, no PM scheduler, and no meter readings. Saying that clearly matters more here than on most pages, because the asset hierarchy and the PM trigger rules are the category, and anyone implying otherwise is selling you a login screen.
What the Vault template gives you is the application around one: organizations as the boundary that assets and work orders scope to, roles and invitations so a contractor sees one customer's equipment and not the rest, a Hono backend with Prisma and Kysely on Postgres, an admin app for looking things up when somebody calls, and Stripe billing if you intend to sell the result. The editor rules that ship with the repository describe how backend features, error handling, and data fetching are structured here, which gives a coding agent project conventions to follow when it writes the asset and work order layer. Its output still needs review.
The parts you write are specific and worth listing before you commit: the asset hierarchy with a self-referencing parent, the work order with its trigger model, the PM scheduler that turns a rule plus a date or a meter reading into a due work order, and the parts transaction that closes with it. If technicians will use it in the field, add the offline sync queue to that list and estimate it honestly, because it is usually the largest item on it.
Below are the screens and packs that make up the starting point. Read them against the five systems above, and if the answer is that an existing CMMS covers all five for less than the build, that is the correct answer.
What is Hype Stack?
Every product starts with the same month of work nobody pays you for: sign-up and login, teams and permissions, taking payments, notifications, an admin panel to run the business. Hype Stack is that month, already built and tested. Start from the free open-source app, add the pieces you need with one command, and keep going on the part that is actually your idea.
Everything lands as real code in your own repository, so there is nothing to rent and nothing anyone can switch off. For the engineers: React 19, Hono, Postgres, and a desktop build, typed end to end.
See it running
Templates are curated project starters built on this stack: a layout, feature packs, a custom theme, and bonus pages. The previews below are recordings of the real apps.
Packs in this stack
Every pack ships real source code: frontend, backend, and admin surfaces where the feature needs them. The ones this stack installs come first; the rest can be composed in later.
Two ways to install features
Same features underneath, different starting point. Either command resolves what the packs depend on, copies the source into your repository, and merges the Prisma schema.
Take a template
A landing page, a design system, a themed layout, and the features already wired into it. Rebrand it, put your product in the middle, ship.
npx @hype-stack/cli template$ hype-stack compose
Compose your own design
Your design and your choices, without rebuilding auth, billing, or notifications. Tick the packs you want and the CLI wires them into the open-source starter.
npx @hype-stack/cli composeQuestions, answered
More stacks
Turn your ideas into
Real applications.
Start free and own every line you ship. When you want more, one All-Access license unlocks every premium pack and template for a year.