Powstania Warszawskiego 15
31-539 Kraków
Skippers on a river, technicians in a plant room, drivers in a yard: the real work happens where coverage is worst. We build offline first mobile apps where the device is the source of truth during the job and sync is engineered, not assumed: no duplicates, no lost photos, and a status the user can trust.
Paste mockup: two phones, app in offline modeThe common thread is not the industry. It is a person with a device, a job that has to be finished on site, and coverage that cannot be relied on for the length of that job.
Long checklists, mandatory photos, findings with severity, a locked record at completion and a report the client receives. Usually filled in basements, plant rooms and steel halls.
Work orders, forms that change by job type, time capture and signatures, with the technician in a crawlspace or a substation. The field service app development page covers the operational side.
The unit as the record, service agreements, refrigerant logs and certificates, captured on the roof where the unit is. See custom HVAC software development.
Proof of delivery, scans, damage photos and exceptions captured in yards, warehouses and loading bays, then reconciled when the vehicle is back in coverage.
Maps that live on the phone, routes and points of interest available without a network, and reference data such as water levels or closures refreshed whenever a signal appears.
Site diaries, snag lists, measurements and photos from places where the signal is a rumour, on rugged devices that get closed, restarted and handed between shifts.
Offline is not a feature you add to a connected app. It is the default state the app is designed for. Connectivity is the exception the app takes advantage of when it appears.
A cached list of jobs is a weekend project. What follows is where the engineering sits, and where an app that looked fine in the demo loses data in production.
Two inspectors work the same site. A dispatcher reassigns a job while the technician is already on it. Both come back into coverage with a valid version of the same record. The app has to decide what wins, per field where it matters, and never quietly discard one side.
The answer is not "last write wins" applied to whole records. It is a sync model designed with you around how your operation actually behaves when people work in parallel.
Photos are the largest thing the app moves and the most fragile. An upload that starts on one bar, stalls halfway and reports success is worse than no signal at all, because the app now believes something the server has never seen.
Uploads are resumable and idempotent. Sending the same photo twice creates one record, not two, and a stalled upload picks up where it stopped instead of starting over.
The form your admin edits on Monday cannot rewrite the record a technician started on Sunday. Definitions are versioned. A record keeps the version it was created with for as long as it exists, and the report for it renders under that version years later.
The same rule covers everything the app is told from the outside: customer lists, equipment records, user roles. Each arrives with a version, and the app knows which one it acted on.
Adoption is decided here. If a technician has ever lost an hour of work to a sync that "should have" happened, they will photograph the screen with their own camera and email it later. The app is now paper with extra steps.
So every record shows its own state, in plain words: synced, pending, needs review. Nothing is dropped without being shown. And closing the app, killing it, or restarting the phone changes none of it, because the local database is what the user is working in.
Some offline first apps carry a map, not just a form, and a map is the largest thing the device will ever hold. On Liniowiec, a river navigation app we built in Flutter, the whole waterway network of over 1,000 km across more than 18 rivers has to work with the phone in airplane mode in the middle of the river.
That means map tiles packaged and cached on the device, a storage budget the user understands, and reference data such as water levels or KML overlays refreshed in the background when coverage returns, without ever blocking navigation. It also means accessibility, because a map used one handed in glare on a moving boat is a WCAG problem, not only a design one.
Tell us where your people lose coverage and for how long. Thirty minutes is enough to say whether offline first is the right shape and what a first version would contain.
Offline first work is rarely a single mobile app. The device, the sync layer, the backend and the office view have to be designed together, or the seams show up in the field.
Liniowiec is a river navigation app we built in Flutter for inland waterways in Poland: over 1,000 km of navigable water across more than 18 rivers, with offline maps as the core of the product rather than an add on. Stage one is live and in use; the next stage extends the map stack, adds water level data and brings the app to WCAG AA.
What it proves for an offline first project: the map, the routes and the reference data have to be usable with no signal at all, refreshed quietly when a signal appears, and never in the way of the person steering.
On TimeFix the work timer had to keep counting when the technician locks the screen, and when the technician places a call from inside the app itself. That was not in the original assumptions and it did not come out of a specification meeting. It came out of technicians using the app on real jobs.
That is the pattern offline first projects are planned around: your own crew works with the app on real sites during development, without signal, and what they find becomes scope while it is still cheap to change.
Every offline first project is scoped in a discovery workshop and priced as a fixed number per stage, with payment on acceptance of each stage. The scope guarantee is simple: everything agreed in the scope works, and if it does not, fixing it is our job, not a change request. On larger contracts we carry a one year warranty on the software.
Who does what, where coverage fails, which systems exist. If the honest answer is a connected app or configuration of what you own, you hear it here.
Where and for how long devices are offline, what is written there, and who else touches the same records. Output is a scoped document and a fixed number.
Large targets, few taps, and sync status visible without hunting. Reviewed with the people who will actually hold the device.
Each stage ends with your own team using the app on real jobs in airplane mode. What they find becomes scope while it is cheap.
Acceptance protocol per stage, code and cloud already in your name, store release included, and the warranty running from launch.
Both handle local storage, background work and sync well. The choice is made at the workshop based on your existing systems, your team and the platform features you rely on, not on a default preference. Either way it is one codebase for iOS and Android.
Days, if the design calls for it. The limit is device storage for photos, not the sync model. The workshop establishes how long your people are actually out of coverage, and the app is built for that with margin.
Field level rules decide what wins where that is safe, and a person is asked where it is not. Completed records are locked, so later changes are new versions with an audit trail. Nothing is silently overwritten.
Usually. The deciding factor is that platform's API: what can be written, how often, and whether custom fields are exposed. We check that in the first days, before scope is written, because it changes the price.
In your own cloud account, in the region you require. For European clients that means EU hosting under GDPR; for US clients a US region. Encrypted in transit and at rest, with role based access, backups and full export.
You do, from the first commit, in a repository under your account. The contract says so in writing, alongside the acceptance protocol and the line between a defect and a change request.
A narrow first version usually runs 12 to 16 weeks from kickoff. A full system with web admin, reports and integrations runs 16 to 24 weeks. Both assume accounts, access and decisions arrive on time.
The scope guarantee covers what was agreed. Beyond that, a monthly support package is available with a fixed number of hours, or you take the code to your own team. Both are normal outcomes and the choice is yours.
Bring how the work runs today, where your people lose coverage and what happens to the data when they do. You will get a straight answer on whether offline first is the right shape, and if it is, a written scope and a fixed price for a first version.
Thomas SiudutCo-Founder and CEO, Apps Value30 minutes, no preparation needed.