We build custom inspection and audit applications for companies whose people work in basements, on roofs, on sites and on board. The app records the visit, proves it happened, works with no signal, and produces the document your client actually receives.
30 minutes with Thomas, no preparation needed.
Generic form tools cover the first week and then meet the parts of the job that make an inspection an inspection. These four are where custom work starts paying for itself.
A checklist gets revised every year. A report issued in March has to keep the wording, the fields and the scoring that applied in March. That means versioned protocols, not an edited template, and it is the single most common reason a generic tool has to be replaced.
A photo is worth something when it carries the time, the place and the item it belongs to, captured on the spot rather than typed in afterwards. The same applies to a signature collected on site and to a reading taken from a device.
Your client does not see the app. They see a document with a header, a finding list, photographs, a conclusion and a signature. Getting that document right is usually more work than the screens that produce it, and it is where reviews are won.
Buildings, machines and vehicles are inspected again. When the history sits on the asset rather than on a pile of separate visits, the second inspection takes half the time and the comparison over years becomes possible.
Most inspection work happens exactly where the connection is worst. Before we quote, we settle which kind of offline you mean, because the three versions differ enormously in effort and only one of them is expensive.
Seeing the schedule and yesterday's data without a connection is straightforward. Completing a full inspection, with photographs, and having it arrive intact hours later is a different build with its own data model. Deciding this early is the difference between a quote that holds and one that moves.
Our approach is set out on offline first app development, and on Liniowiec, a river navigation app, routes are loaded before departure precisely because the connection cannot be trusted mid journey.
We work backwards from the finished document. Once we know what has to appear in it, and who signs it, the fields on every screen answer for themselves and the scope stops being a matter of opinion.
That covers the layout and branding of the report, whether findings carry a severity or a pass and fail, how photographs are placed against them, what happens when a follow up visit closes a finding, and where the file ends up: sent by email, dropped into the client's system, or waiting in a portal.
It is the same discipline we use on field work generally, described in our guide to what a field service app has to capture in version one.
Every inspection app we have been asked to rebuild was replaced for the same reason: the tool could record the visit, but it could not produce the document the business is actually paid for.
Bring one real inspection, start to finish, and we will tell you what version one has to hold.
Book an intro callThe industry changes the vocabulary and the compliance rules. The mechanics underneath are the same, which is why work in one of these areas transfers cleanly to the others.
Periodic reviews, safety and fire checks, handover inspections, and portfolios where the same property returns every year.
Installations, service contracts and legally required checks, where the device itself is the record and its history matters more than any single visit.
Pre use checks, damage documentation and condition reports, usually with photographs as the main evidence and a short window to complete them.
Sites, vessels and remote assets where connectivity is unreliable by nature and the inspection has to complete regardless.
A first release that covers one inspection type completely is worth more than one that covers four partially. This is the split we recommend, and the reason a project of this kind can be quoted at a fixed price at all.
Two of our own products carry most of the lessons that end up in an inspection build.
A tool for service technicians where the work timer had to keep counting while the phone was locked or a call was taken from inside the app. That requirement appeared once people used it on real jobs, not in the specification. Before the app covered every case, technicians were writing things in a phone notepad, and those notes drifted away from the system. The case is on our TimeFix page.
River navigation for crews who lose connectivity as a matter of course. Routes and their versions load before departure and the app behaves the same afterwards, which forced the data model to be right the first time. It is the clearest example of the deeper kind of offline described above, and of why that decision belongs at the start of a project rather than in the middle.
A first version covering one inspection type end to end is usually a matter of a few months rather than weeks, and offline capture is the part that moves that number most. We give a date with the quote, after the scope is written.
It depends on the number of inspection types, how deep the offline requirement goes, and what has to be integrated. We quote a fixed price after scoping. Current ranges are on our pricing page.
Many companies should. Custom starts making sense when your protocols are your own, when the report is part of what clients buy, or when the tool has to fit an operation rather than the other way round.
Usually yes, provided that system has a usable interface. Name every system it must talk to in the first conversation, because a missing interface changes the estimate more than any feature does.
Both, from one codebase, in Flutter or React Native depending on what your company already runs. The reasoning behind that choice is in our guide to Flutter and React Native.
You do. The repository, the Apple and Google accounts and the third party services belong to your company from day one, and ownership is written into the contract.
Everything agreed in the fixed scope is our responsibility to keep working. Ongoing changes and platform updates are covered under mobile app maintenance services.
Then an audit comes before any rebuild. We look at the codebase and tell you whether it can be continued or not, which is what app rescue covers.

Walk us through a single visit from assignment to signed report, including the part that goes wrong today. That one conversation is usually enough for us to say what version one needs to hold and what it would take to build it.
Book an intro call