A maintenance management app is a history kept per asset, not per job.
A task list tells you what is open today. A maintenance management app tells you that pump 3 has been repaired four times this year, that two of those were the same seal, and that the last planned service was skipped. Everything else, the scheduling, the scanning, the parts, exists to keep that one record honest. It is the same record that makes preventive maintenance apps worth running at all.
This page covers how preventive schedules should actually fire, how a technician identifies the machine in front of them, what belongs on a work order when the job is closed, and what a year of that history is for.
See when the next service is really dueThe short version
Work orders are cheap to collect, asset history is what you are buying.
Three things separate this from a shared to-do list. Every job is attached to an asset, so the record accumulates in one place. Schedules generate work on their own, from dates or from runtime, without anyone remembering. And the closing fields are specific enough to count later: what failed, why, how long the asset was down, what it consumed.
Most of the category is sold as a CMMS app, short for computerised maintenance management system, and the acronym hides how small the core is. Skip any of those three and you get an app that clears jobs and remembers nothing, which leaves the repair or replace question with no evidence behind it.
Calendar intervals, running hours and the PM that never fires
A preventive schedule is a rule that creates work without anyone asking. Three rules cover almost everything. A calendar rule fires every 90 days. A meter rule fires every 500 running hours, or every 10,000 kilometres, or every 250 cycles. A condition rule fires when a reading crosses a threshold: vibration, temperature, pressure drop across a filter.
Calendar rules are easy and wrong for anything with variable use. A standby generator that runs twenty hours a year and a lead pump that runs sixty hours a week do not wear at the same rate, and a quarterly service treats them as though they do. One is serviced for nothing, the other far too late. Meter rules fix that but need a reading, so the real design question is where the reading comes from.
The decision people make by accident is whether the next due date counts from the scheduled date or from completion. Fixed scheduling keeps the original cadence, so a service done a week late still leaves 83 days to the next one. Floating scheduling restarts the clock at completion, so lateness accumulates and a quarterly task quietly becomes a four monthly one. Compliance, the share of planned jobs closed inside their window, only means anything if that window is a field in the app rather than an argument afterwards.
Try it
When the next service is really due
One asset, scheduled two ways. A calendar rule counts days. A meter rule counts running hours. They agree only by accident.
Runtime says 32 days, calendar says 34 days
The runtime rule fires first, 2 days ahead of the calendar. Schedule this asset on the calendar alone and it works 2 days past the interval it was built for.
The technician should scan, not search
Somebody standing in front of a machine should not be typing a description of it into a search box. The asset carries a tag, the phone reads the tag, the asset record opens: history, manuals, open jobs, the last few readings. That single interaction is most of what field users judge the app on, and an equipment inspection app is judged on exactly the same moment.
Pick the tag for the environment, not for the demo. Printed QR and Code 128 labels are cheap and any phone camera reads them, but they fail under paint, solvent and heat. NFC tags cost more per asset and need no line of sight and no focus, which matters in a dark plant room or through wet gloves. Engraved plates outlast both and need a human to read the number. Most sites end up mixed, so the app has to accept all three routes to the same record, plus a search by location for the tag that has been painted over.
Encode your own asset ID, not a link into a system you might replace. A code that reads ASSET-04412 still works when the app is rewritten. A code that reads a vendor URL becomes a relabelling project the day you change vendors.
On the build side none of this is exotic. Expo's camera component takes a list of code types to watch for, including QR, Data Matrix, PDF417, Code 39 and Code 128, and hands back the type and the decoded string, which you use as a key into your own asset table. Newly generates React Native and Expo projects, and its cloud simulator has a webcam injection control that feeds your computer camera into the device, so a printed tag can be held up to a laptop and read before the app is on a phone. That control is documented, but we did not run a build and watch a scan open a record end to end, so treat scan to record as standard Expo behaviour rather than something we timed. NFC needs a real handset, because a simulator has no NFC radio, and it is one of the iOS entitlements that has to be turned on for the bundle ID before signing.
What a finished work order has to say
A job that closes with the single word done is a job cleared and a record lost. The fields that matter later are the ones nobody wants to fill in at the end of a shift: what failed, the cause, what was done about it, how long the asset was unavailable, which parts came off the shelf, how many labour hours went in, who signed it off. Free text is good for detail and useless for counting, so the first three want a short coded list.
Downtime repays the effort most. Record when the asset stopped and when it ran again, separately from when the job was opened and closed. A four hour repair that started the morning after the failure cost twenty hours of availability, and only one of those pairs of fields knows that.
Where a job involves isolating energy, the procedure is not a note in the app, it is a regulated document. The federal lockout and tagout rule requires that procedures for controlling hazardous energy be developed, documented and used, and that they be inspected at least annually by an authorised employee other than the ones using the procedure being inspected. The certification has to identify the machine or equipment, the date, the employees included and the person performing it. Those four fields are a small table in your app.
Intake is worth separating in your head from the maintenance side, because most requests arrive from people who are not technicians. Somebody reports a fault in whatever words they have, and something has to turn that into an assignable job. Anyone searching for a work order maintenance app is usually looking for that screen, and it is the whole subject of a work order app.
29 CFR 1910.147, the control of hazardous energy, lockout and tagout
A year of history, and what it is for
Everything an asset maintenance app collects is worth exactly what you can add up later. Cost over the life of an asset settles repair or replace arguments, and it is only labour hours plus parts issued, summed by asset ID. Issue parts to a job rather than to a person or a cost code and that number comes for free.
Mean time between failures is the other one worth having, and it only means anything if unplanned work is distinguishable from planned work. Marking each job as planned or reactive when it is created makes the split trivial. Leaving it out has you reading job titles a year later and quietly rounding.
Spares are where a small app beats a large one. You do not need inventory control. You need a count, a reorder point and a note of which assets each part fits, so the person who takes the last seal triggers an order instead of finding the shortage during the next breakdown.
What each approach gives a maintenance team
| Option | Work orders tied to an asset | Scan a tag to open the record | Usable with no signal | Matches your PM rules |
|---|---|---|---|---|
| Paper job cards and a wall planner | No | No | Yes | only if somebody remembers |
| Shared spreadsheet | partly | No | a stale copy | until the rules change |
| Off-the-shelf CMMS | Yes | Yes | varies by vendor | if your rules fit theirs |
| Enterprise asset management suite | Yes | Yes | Yes | after a configuration project |
| A maintenance app you build | Yes | Yes | if you design for it | Yes |
Building one around your own plant
Off-the-shelf maintenance products are priced per technician per month and shaped around a generic plant. They fit until your rules stop being generic: an asset that belongs to a tenant rather than to you, an interval defined by two meters at once, a permit signed by somebody who never opens the app, a PM calendar that bends around a shutdown week. That is where the configuration screens run out and the spreadsheets come back.
Newly is an AI app builder. You describe the app you want, including the rules your site actually runs on, and it writes a real React Native and Expo project you own, runs it on a cloud simulator while it builds, and ships iOS builds to TestFlight. Android builds go to Google Play internal testing from the Deploy tab, or out as a standalone release APK you install directly. It costs $25 a month and there is no free plan. It arrives with no asset taxonomy and no parts catalogue, which is the point when your taxonomy is the thing nobody else has.
Before you design a single screen, settle what the app does in a plant room with no signal. Half of this work happens where there are no bars, and the answer shapes your data model rather than your interface.
Questions people ask about maintenance management apps
It is an app where every job is attached to a specific asset, so the work accumulates into that asset's history. It holds an asset register, work orders raised against those assets, schedules that create work automatically, and the parts and hours each job consumed. The history is the product.
Describe the plant you actually run
Write down your asset list, the rules that should generate work on their own, and the one report you always end up rebuilding in a spreadsheet. Build the app around those three.
Start building