Inspections are done on paper, photographed, emailed, and retyped by somebody in the office three days later. Here is the model behind an app that ends that, the prompts to build it, and what it takes to run it.
Your private status link is on its way to your inbox.
A field inspection app is four parts: a checklist that works on a phone with one thumb, offline capture that syncs later, photo and location evidence attached to the specific item that failed, and an exception path that routes a failure to somebody before the inspector leaves site. Offline is the requirement people underestimate. Inspections happen in basements, warehouses, lifts and sites with no signal, and an app that needs a connection gets abandoned on the first visit.
Inspections
3
Held offline, not yet synced
14
Items on this round
2
Failed, jobs raised
11 min
Average per inspection
Location
Plant room B, Level 2
Captured automatically with the timestamp
Emergency lighting
Pass
Default. You only tap the exceptions.
Fire door, north
Fail
Photo required by the template
Photo
1 attached, annotated
Held against this item, not the inspection
Last month, same item
Failed. Job closed 12 Aug.
Shown while you are looking at it
Pressure gauge
2.4 bar
Reading, expected range 2.0 to 3.0
You run facilities, operations, field service, health and safety, or quality. People go and look at things and write down what they find. What you want is that record to arrive complete, on the day, with the photos attached to the right items.
What happens on a round, including the part where there is no signal.
Templates, locations and the previous results, cached on the device so none of it needs a connection later.
So the only interactions are the exceptions, which is what makes an inspection take eleven minutes rather than forty.
Photo, note and reading attached to that item, annotated on the phone if a mark explains it better than words.
An inspector who can see this item also failed last month reports it differently.
With the queue state on screen, because somebody in a car park needs to know their morning's work is safe.
Routed by severity before the inspector leaves site, rather than three days later when somebody retypes the form.
An inspection app is not a form on a phone. It is four parts, and the second one decides whether it survives contact with a basement.
Built for one thumb, in gloves, in bad light. Large targets, a clear pass and fail, and as few free-text fields as you can manage.
The whole inspection completes with no connection and syncs when there is one, with the sync state visible so nobody wonders whether it saved.
Photos, notes, a reading and a timestamp attached to the specific item that failed, not to the inspection as a whole.
A failure raises a job with an owner and a due date, routed by severity, before the inspector has left the site.
These prompts start from a Helix project, which is what handles sign-in, credentials and hosting. Start with Helix
Paste these into Claude Code, Codex or Cursor in order. Each one leaves you with something that runs, so you can stop after any step.
Built for a phone in a basement, not a desk.
In this Helix project, build me a field inspection app. It will be used on
a phone, outdoors or in a plant room, sometimes in gloves.
Templates: an inspection type with an ordered list of items, each with a
description, a response type (pass or fail, a reading with a unit, a
choice from a list, or a count), whether it is mandatory, and whether a
photo is required when it fails.
Inspections: the template used, the location, the asset if there is one,
the inspector, the start and finish time, and a response per item.
Design the capture screen for a phone first and a desk second. Large tap
targets, one item at a time or a short scrollable list, pass as the
default so the inspector only interacts with exceptions, and as little
free text as possible.
Capture the timestamp and location automatically. An inspection record
that depends on somebody typing the date is a record you cannot rely on.
I sign in through Helix, so do not build a login page. Read the signed-in
user from the runtime. And do not put any key or connection string in the
code: if this needs to reach another system, tell me and I will create the
connection in my workspace.Worth knowing. Defaulting every item to pass sounds like it invites rubber-stamping. It does the opposite: it means the only taps are the exceptions, so the exceptions get attention.
The requirement people underestimate and the reason these apps get abandoned.
Now make the whole thing work offline, because this is the part that decides
whether the app survives.
An inspector must be able to open a template, complete every item, attach
photos and finish an inspection with no connection at all, then have it
sync when they get signal.
Show the sync state clearly on the device: how many inspections are held
locally, when the last sync happened, and whether anything failed to
upload. Somebody standing in a car park needs to know their morning's
work is safe before they drive away.
Handle photos properly, because they are the thing that breaks this.
Compress on the device, queue them separately from the inspection record
so a slow photo upload does not block the data, and retry.
Never lose an inspection to a failed sync. Keep it locally until upload
is confirmed, and make a stuck one obvious rather than silent.Not a gallery at the end.
Attach evidence per item rather than per inspection.
When an item fails: require a photo if the template says so, allow a
note, and record the reading if there is one. Keep all of that against
that item.
A gallery of twelve photos at the bottom of an inspection with no
indication of which item each belongs to is not evidence, and it is what
almost every paper process produces.
Let the inspector annotate a photo with a mark or an arrow, because
"the crack is on the left-hand bracket" is much clearer drawn than
written on a phone.
Show the previous inspection's result for the same item while they are
looking at it. An inspector who can see that this item also failed last
month reports it differently.Because a fault raised three days later has been walked past a dozen times.
Add the exception path, and make it fire on completion rather than after
somebody reviews the paperwork.
Each failed item raises a job: what failed, where, the evidence, a
severity from the template, an owner routed by severity and location, and
a due date derived from the severity.
Critical failures notify immediately. Everything else lands in the
owner's queue.
Track each job to closure with evidence of the fix, and show it on the
next inspection of that item, so an inspector can see whether the thing
they raised last time was ever done.
Then report: completion rate against schedule, items that fail most
often, locations that fail most often, average time to close a job by
severity, and repeat failures at the same location. That last one is the
finding. One failed item is a job; the same item failing every month is a
different problem and nobody sees it from individual inspections.Worth knowing. Showing the previous result and whether the job was closed turns a series of inspections into a history, which is the only way a repeat failure becomes visible.
The step that turns a working prototype into something with your data in it.
Now connect it to the systems we actually run, so it works on real data
rather than the rows you seeded.
Anything in angle brackets is a placeholder. Swap it for whatever we use
instead, and have the app name the connection it wants rather than assume
a vendor, so changing my mind later is a config change and not a rewrite.
<Okta>. Identify the inspector, because an inspection is only evidence if
you know who did it.
<Jamf>. Push the app's url to managed phones as a web clip, and confirm
the device doing the inspection is one of yours.
<Jira>. Raise the job from a failed item into the queue the maintenance
team already works from.
<Slack>. Notify immediately on a critical failure, rather than waiting for
the inspection to be reviewed.
<Google Drive>. Store photos and signed inspection records where retention
rules already apply.
<NetSuite>. Read the asset register so an inspection is against a real
asset rather than a typed location.
<Snowflake>. Push inspection history into the warehouse, which is how
repeat failures across locations become visible.
Only write where I have said to write. Everything else is read only.
Do not write a key, a token or a connection string anywhere in the code,
and do not ask me to paste one. Tell me which connections you need and I
will create each as an authentication in my Helix workspace. Reference
them by alias.Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.
The last step of every build: a URL, and the right people on it.
Deploy my app.Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL that works on a phone. Inspections carry location and photo evidence, so set Access Control before sharing.
An inspection app is mostly self-contained on the device, and connects at the two ends: what to inspect, and what to do about a failure.
Okta
Identify the inspector, because an inspection is only evidence if you know who did it.
Jamf
Push the app's url to managed phones as a web clip, and confirm the device doing the inspection is one of yours.
Jira
Raise the job from a failed item into the queue the maintenance team already works from.
Slack
Notify immediately on a critical failure, rather than waiting for the inspection to be reviewed.
Google Drive
Store photos and signed inspection records where retention rules already apply.
NetSuite
Read the asset register so an inspection is against a real asset rather than a typed location.
Snowflake
Push inspection history into the warehouse, which is how repeat failures across locations become visible.
Each line says whether the app reads, writes or both. Anything not described as writing should be read only.
Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.
Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.
The build gets you a working app. It produces evidence that may be relied on for safety or compliance, and it runs on personal phones, so it needs to be run properly.
AI Deployment
One command takes the app from your assistant to a live address, so the people who need it get a link rather than instructions for running it locally.
App Security
An inspection record is only evidence if the inspector is identified. SSO means every inspection carries a verified name rather than one typed into a box.
App Security
Raising jobs in a maintenance system and reading the asset register needs real access. Granting it to the app rather than pasting a key into it means it can be rotated or revoked without a redeploy.
App Registry
Every app carries a named owner and an entry IT can see, so the tool does not become nobody's problem when the person who built it changes role.
Cost Management
Per-app spend visibility, with budgets and caps, so an internal tool cannot quietly become a line item nobody can explain.
A phone-first checklist for people who go and look at things: capture offline, attach photos and readings to the specific item that failed, and raise a job routed by severity before the inspector leaves site.
Because inspections happen in basements, plant rooms, warehouses and sites with no signal. An app that needs a connection gets abandoned on the first visit and everyone goes back to paper, which is the outcome you were trying to avoid.
Because a gallery of twelve photos with no indication of which item each belongs to is not evidence. It is also exactly what a paper process produces, so an app that repeats it has added nothing.
Because a fault raised three days later, after somebody in the office retypes the form, has been walked past a dozen times. Routing by severity at the moment the inspection finishes is most of the value.
Repeat failures at the same location or on the same item. One failed item is a job. The same item failing every month is a different problem, and it is invisible from reading individual inspections.
Yes. The prompts here are written for Claude Code, Codex or Cursor and stage the build, with offline handling as its own step because it is the part that decides whether the app survives. The judgement calls are your templates and severities.
IT and Operations
One record per device and licence, with an assignment history, a lifecycle, and a reconciliation against what your systems actually report. Prompts to build it, and what it takes to run it.
IT and Operations
Track what you hold by movements rather than a quantity field, reconcile against a physical count, and reorder before you run out. Prompts to build it, and what it takes to run it.
IT and Operations
Record incidents with a consistent timeline, run postmortems to a fixed template, and track the action items until they are actually done. Prompts to build it, and what it takes to run it.
Last reviewed September 2026.
Helix is the governed runtime for AI-built apps. Deploy what you build, put SSO in front of it, connect it to your systems with managed credentials, and give it a named owner.
Your private status link is on its way to your inbox.