How We Built an Offline-First Field Audit Platform for a National Senior Care Accreditation Body

The situation

Our client accredits senior care providers across the country. Their auditors travel to skilled nursing facilities, assisted living communities, hospice agencies, home health offices, and retirement communities to perform structured on-site assessments. The audit protocols are well defined. The audit environment is hostile to software.

In residential and clinical buildings, Wi-Fi is inconsistent at best. Guest networks are locked down. Cellular coverage drops in stairwells, basements, and rural facilities. Assessors are routinely on the road between sites for hours at a time. The legacy assessment workflow assumed a connected web application, which meant assessors faced a poor choice on every audit: pause mid-walkthrough to wait for a connection, or switch to paper and re-key their notes from a hotel room that night.

Re-keying is slow. It is error-prone. And after a long day in the field, it is the kind of work that erodes a workforce.

Connectivity was the operating assumption the original system was built on. It was also the assumption least supported by the actual field environment.

The client engaged us to rebuild the assessor experience from the ground up. The mandate was direct: the application has to work, fully, in the absence of a network.

The challenge

Four problems had to be solved in parallel, not in sequence.

1. Offline as the default. The application needed to launch, load protocols, capture an entire assessment, and persist work without ever requiring a successful network call. Offline could not be a degraded mode. It had to be the operating mode.
2. A sync model that did not lose data. When connectivity returned, every action taken offline (sometimes hours or days of work) had to reach the server safely, in order, without silent failures and without overwriting newer state on the server.
3. Multi-assessor parallelism. Larger properties are audited by multiple assessors working different sections of the protocol at once. Two people working the same record while both offline cannot be reconciled with a last-writer-wins policy. That is data loss with a timestamp on it.
4. Adoption without an MDM program. The client did not want to fund a native iOS and Android build, an enterprise developer program, or a mobile device management rollout. The platform had to feel native enough that assessors would actually use it on personal and field devices.

The approach

The operating model

We delivered with a 6-person cross-functional pod, structured around a tech lead, a small engineering team, and embedded coordination with the client's product and audit operations stakeholders. The build phase ran on a tight cadence with regular demos to assessor representatives, because this was a workflow product, not a back-office system, and getting the field experience right required field feedback in the loop.

The engagement closed with a deliberate 3-month maintain-and-train phase. ExeQut continued to operate the system in production while transferring knowledge to the client's engineering team through pairing, code walkthroughs, runbooks, and on-call rotation handoffs. Knowledge transfer was treated as a deliverable, not a courtesy.

The technical architecture call: offline-first, not offline-tolerant

The single most important architectural decision was philosophical. We did not build a connected app and then add offline support. We built an offline app and treated connectivity as a feature.

Offline was the default operating mode, not a fallback. Connectivity, when it appeared, was used to sync. The application was never permitted to depend on it.

In practice this meant the assessor's device had to hold everything required to complete an audit before they ever left for the property: protocol definitions, prior assessment context, reference data, and the local storage to capture every input. We built the front end in React with a Redux Toolkit store and used IndexedDB through Dexie for durable local persistence. A hand-rolled service worker handled asset caching, offline routing, and the lifecycle of the installable PWA.

We chose a Progressive Web App rather than native builds for a specific reason: distribution. The client did not want to manage app store releases or stand up an MDM program for a workforce that was already using personal and assigned field devices. A PWA could be installed to the home screen with one tap, launch full-screen, and persist offline state without going through any store or device management intermediary. Most assessors voluntarily installed the app to their home screens, which retroactively validated the choice.

The backend: a .NET Core API designed for asynchronous reality

The API was a .NET Core Web API hosted on Azure App Service. The interesting design work was not in the framework choice. It was in the contract.

Every write endpoint was idempotent. Every record carried a version. Every submission carried a client-generated identifier so that retries from a flaky network produced exactly one server-side effect. Optimistic concurrency was enforced at the record level so that late-arriving offline writes could be evaluated against current server state rather than blindly applied. The result was an API that behaved correctly when a client showed up days late carrying a backlog of work, which is the actual operating profile of a traveling assessor.

The Azure foundation

The platform was designed for production operation in a healthcare-adjacent environment, which raised the bar above "it runs in the cloud." The footprint was small enough to be operable by a lean engineering team, and intentional enough that every service in it had a defined job.

Compute and data ran on Azure App Service and Azure SQL. Assessor-captured evidence (photos, scanned documents, supporting attachments) was handled separately on Azure Blob Storage. Offline, those files were queued on the device alongside the structured assessment data and uploaded to Blob when connectivity returned. The audit record carried a reference, not a payload, which kept the API endpoints small and the upload path independent of the assessment submission path.

Identity ran through Entra ID, with Managed Identities doing the heavy lifting on the platform side so that App Service could authenticate to Azure SQL, Key Vault, and other Azure services without storing a credential anywhere. Azure Key Vault held the secrets that did exist: signing keys, certificates, and the third-party connection strings that lived outside the Managed Identity model. Azure App Configuration carried runtime configuration and feature flags, which made operational changes possible without a redeploy and gave us a clean way to ship features dark and roll them out under control.

Networking was deliberate. The public surface of the platform was an Azure Front Door instance with WAF in front of the API; everything past that edge lived inside a VNet. Azure SQL and Key Vault were reached over Private Endpoints rather than the public internet, which meant credential discipline was not the only line of defense between the database and the world. PWA static assets were served through Azure CDN, and that choice mattered more than it usually does: assessors travel, and an edge-cached app shell is the difference between a usable cold load on a hotel network and a frustrated assessor in a parking lot.

Observability was instrumented from day one. Application Insights captured request traces, dependency timings, and exception telemetry from the .NET API. Azure Monitor and Log Analytics aggregated platform metrics and logs across every service in the footprint. We built custom dashboards and alerts focused on the signals that actually predicted user pain: sync queue depth, failed-job rates, conflict resolution backlog, authentication failures, and Blob upload latency. The on-call rotation could see, in one place, whether the platform was healthy from the perspective of a traveling assessor, not just from the perspective of a server.

The combination was not infrastructure as decoration. Every service in the footprint earned its place, and the result was a platform that an in-house team could realistically own after the engagement closed.

The sync engine: a durable client-side job queue

Between the offline-first client and the idempotent server, we built a durable job queue on the device. Every assessor action that required the server (creating, updating, completing, attaching) was captured as a job in IndexedDB. The queue persisted across app restarts, device reboots, and PWA reinstalls.

When the device returned to connectivity, the queue drained in order. Successful jobs were reconciled against server state. Failed jobs were not silently dropped; they surfaced to the assessor with the option to inspect, retry, or escalate. The assessor never had to ask whether their work was saving. The answer was always yes.

On a field device, "did my work save?" is not a UX question. It is a trust question. We answered it with architecture, not with a notification toast.

Multi-assessor conflict resolution

For properties audited by more than one assessor in parallel, last-writer-wins was not an acceptable sync policy. We implemented per-field conflict detection on the server. When two offline edits to the same field arrived from different assessors, both versions were preserved, the conflict was flagged on the lead assessor's view, and resolution happened inside the application with a full audit trail recording who made which change and when.

This is the kind of feature that is invisible when it works and catastrophic when it does not. Audit integrity depends on it.

Identity in an offline-first world

Entra ID was straightforward as a platform choice; making it work for an offline workforce required a more careful design. Token caching on the device was tuned to keep an assessor authenticated across an offline window so that walking into a basement with no signal did not invalidate a session in the middle of a walkthrough. Sensitive data on the device was scoped to the assessor's active engagements and cleared on completion, so a lost or replaced device did not become a long-term data exposure. The intent was that authentication never became the reason an assessor could not finish a property.

Deployment and release automation

Releases ran through Azure DevOps pipelines that we built out end to end. Branch-based merges drove automated deployments into the appropriate Azure environments, with manually triggered pipelines reserved for production promotions, hotfixes, and any release that needed a human gate. The result was a release process that was boring on purpose: predictable, auditable, repeatable, and not dependent on tribal knowledge to operate. Pipeline definitions, environment configuration, and approval gates were treated as part of the codebase, which made the eventual handoff to client engineers a matter of reading the repo rather than reading our minds.

Handoff

The system was released to production on a controlled rollout, validated against real audit cycles, and then run by ExeQut for an additional period before transition. The 3-month handoff phase was structured: regular engineering working sessions, a documented runbook for the sync engine and conflict resolution, walkthroughs of the Azure DevOps pipelines, and a deliberate transfer of on-call responsibilities. By the end of the window, the client's engineering team owned the platform in full, including the deployment toolchain.

The outcome

Assessors can now complete a full property audit, start to finish, without an internet connection. The PWA loads instantly, captures every input locally, and syncs cleanly the moment connectivity returns. Travel time is no longer absorbed by re-keying paper notes from a hotel room. Multi-assessor parallel work on a single property is supported safely, with no silent overwrites and a complete audit trail of every change.

The voluntary PWA install rate among assessors was high, which validated the decision to skip native builds and an MDM program. The platform handled multiple full audit cycles in production before handoff, and its modern foundation (React with Redux Toolkit, .NET Core, Azure App Service, Azure SQL, Azure Blob Storage, Entra ID with Managed Identities, Key Vault, App Configuration, private networking with WAF, and full Application Insights instrumentation, all delivered through Azure DevOps pipelines) is supportable and extensible by the client's engineering team to other accreditation lines as the program evolves.

We estimate the change is worth a seven-figure annual recovery to the client. The estimate is built bottom-up from assessor headcount, the typical re-key hours absorbed per audit cycle, and the loaded cost of recovered field time, taken together with reduced re-key effort, recovered assessor productivity, and faster accreditation cycle times. The figure is engagement-derived but directional rather than precise. The qualitative effect, which is harder to put a number on, is that an experienced field workforce is no longer being asked to fight their tools.

What we took from it

A handful of lessons we would carry into the next engagement of this shape, written for the program manager or engineering leader who has to make these calls themselves.

1. Offline-first is an architectural decision, not a feature flag. If you build a connected app and then try to bolt on offline support, you will spend the rest of the project's life apologizing for it. Decide on day one which mode is the default.
2. PWAs are credible substitutes for native apps in field operations. When distribution, installability, and offline capability are the goals, and you do not need deep platform integration, a well-built PWA avoids an entire category of native and MDM cost without compromising the experience.
3. Sync correctness lives in the API contract, not the client. Idempotency, versioning, and conflict semantics belong in the server's vocabulary. A clever client cannot rescue an API that assumes writes happen in real time.
4. Multi-user offline is a data integrity problem. Treat it that way. Surface conflicts to humans who have authority to resolve them, preserve both sides until they do, and record the resolution in the audit trail.
5. Plan the handoff before the build is finished. The most successful modernization engagements end with the client's team owning the platform, not a continued dependency on the vendor. Runbooks, pairing time, and a structured transfer window are deliverables.