Guides

Choosing a fire door inspection app: the questions worth asking

Six things to test before you commit to an inspection app — offline capture, physical tags, client access, forms, reporting and permissions — with how to test each one, and where MyQTAG stands on it.

Published
8 September 2026

Most fire door inspection apps demo well. They are demonstrated on a laptop, on wifi, with three doors in a building somebody chose. Your objection surfaces four months later, in a stairwell, with no signal, on day two of a 400-door block.

So this is a list of questions, not a review. We have deliberately not written about anybody else’s product: we cannot test what their software does under your conditions, and neither can you from a feature table. What you can do is ask every supplier the same six questions and insist on seeing the answer rather than hearing it.

That includes us. Each section ends with where MyQTAG stands, marked as such, so you can hold this guide to its own standard.

1. Does capture actually work with no signal?

The question. Not “is there an offline mode” — almost everyone says yes. The question is what the offline mode contains, and what happens at its edges.

How to test it. Ask for a trial on a real device. Then, before you leave the office, sync a project. Put the phone in airplane mode and keep it there. Now:

  • Can you open the job at all, or does the list need a round trip?
  • Can you attach photographs, capture a signature, drop a pin on a floor plan?
  • Can you start a second inspection while the first is unfinished?
  • Force-quit the app mid-inspection and reopen it. Is the work still there?
  • Come back online. Does everything upload without you doing anything, and can you tell which items are still in flight?

The last two are where most systems actually fail, and they are the two nobody demonstrates.

Where MyQTAG stands. Operatives sync a project before they go and then work entirely on the device — inspections, photographs, signatures and floor-plan pins — with no connection at all. Work uploads when the phone next has one. This is the part of the product we would most encourage you to test adversarially rather than take our word for; see the mobile app.

2. Is there something physical on the asset — and who owns its history?

The question. How does the operative in front of a door know which record it is? If the answer is “they find it in a list”, you have a search problem on every visit and a mis-selection problem on some of them.

And the deeper question: when you lose the contract, whose is the history?

How to test it. Ask what physically goes on the asset, whether it survives a corridor being repainted, and what happens when a label is damaged. Then ask what a different organisation sees if they scan it. Ask whether a member of the public with a phone camera can open it, and what they see if they do.

Where MyQTAG stands. QTAG labels are ordered in the platform and assigned to assets; the QR opens the tag’s page in any phone camera with no app installed. A damaged label is replaced and the new tag carries the old one’s history, with the old reference still resolving forward. And the history is readable across organisations — a building manager and their contractor each see the same door’s record in their own account. The reasoning behind that, and its limits, is in the golden thread guide.

3. Can your client see the work without you emailing PDFs?

The question. Emailing reports is not client access. It is a distribution method that ages badly: the client’s copy is stale the moment anything changes, you cannot tell whether they opened it, and revoking one is impossible.

How to test it. Ask whether the client gets an account or a file. If an account: what do they see, can they see it without seeing your other clients’ work, and does it cost you per client. If a file: ask how you would withdraw one that went to the wrong address.

Where MyQTAG stands. Client organisations get their own login and see the work recorded against their buildings by the contractors they are connected to — not an inbox of attachments. Where a file genuinely is the right answer, shared files are signed links you can revoke, with a log of who opened what.

4. Are the forms yours, and are they versioned?

The question. Two separate things, and the second is the one that catches people. Can you build your own inspection form — and when you change it, what happens to the six hundred inspections captured against the old one?

A system that edits forms in place quietly rewrites your history. Last year’s inspection now claims to have answered a question that did not exist last year.

How to test it. Build a form. Capture an inspection against it. Change the form. Then go back and open the original inspection and see what it says.

Where MyQTAG stands. You build and version your own templates and publish them to devices; an inspection stays attached to the version it was captured against. See forms and reports.

5. What comes out at the end — and can you take it with you?

The question. The report is the thing your client actually judges you on. And the export is the thing that determines whether you are a customer or a hostage.

How to test it. Ask to see a real generated report, with your branding, not a template screenshot. Then ask the awkward one: if we leave in three years, what do we get, in what format, and does it include the photographs.

Where MyQTAG stands. Approving a job generates a client-branded PDF, with branding chosen per project. Bulk exports and every generated report live in a file manager you can pull from.

6. Who can do what, and can you prove who did it?

The question. An inspection record that anybody can edit afterwards is not evidence. Neither is an approval that does not name an approver.

How to test it. Ask who can change a submitted inspection, whether that change is recorded, and who is allowed to approve. Then ask to see the trail on a record that has been through a rejection and a resubmission — the tidy path tells you nothing.

Where MyQTAG stands. Roles run owner, admin, member and guest. Approvers are named per form per project — any admin, the responsible person, or a specific person — and every lifecycle move on an inspection (submitted, review started, approved, rejected, returned, recalled, withdrawn) is written as its own event with the person who made it.

The commercial questions

Not a criterion so much as a set of things worth settling in writing before you commit, with any supplier:

  • Is it charged per user, per asset, or per site — and which of those grows fastest for your business?
  • Are client logins charged, and to whom?
  • What is included in a trial, and what happens to the data you capture during one if you do not continue?
  • How long is the commitment, and what is the notice period?

Ask us those too. If a supplier is vague about the fourth one, that is the answer.

Before you sign anything

Run one real job. Not a pilot in the office — an actual visit, on actual doors, in the worst signal you have, done by the operative who will use it every day rather than by whoever is keenest.

Then look at what came out the other end and ask whether you would be content to hand it to a client, and whether somebody who was not there could understand it in two years.

If you would like to do that with us, book a demo — there is no payment step in the form — or ask us the awkward questions first.

See it on one of your own jobs.

Twenty minutes on the week you actually have: survey, install, remedial, periodic — captured on the phone with no signal and approved in the office.