What to Ask a Mobile Vendor Before Trusting Them With Offline Field Operations: 2026 Guide for US Enterprise

Every mobile development vendor will tell you they can build offline capability. The question is whether they mean they have done it in production for an enterprise field team, or whether they mean they have used a device database before. The difference is $50,000-$150,000 in rework cost and six months of your technicians using an app that fails in the field. The questions below take 20 minutes in a live call and separate vendors who have shipped production offline-first apps from vendors who have not.

Why most vendors fail this evaluation

Offline-first capability is technically achievable but operationally complex. Every mobile developer knows how to use a local database. Not every mobile developer has designed a conflict resolution strategy for a 50-person field team where two technicians can both update the same work order while each has no signal.

The gap shows up in production, not in demos. A demo app can appear offline-capable with a small data set, clean test scenarios, and a vendor-controlled environment. The same app deployed to 50 technicians with real work order volumes, real connectivity patterns, and real conflict scenarios fails in ways the demo did not.

The questions below are designed to reveal that gap before you sign a contract. They are not trick questions. A vendor who has built production offline-first apps will answer them easily. A vendor who has not will struggle, redirect, or give answers that do not hold up to a follow-up.

Use these questions in a live technical call with the engineer who will lead your build - not the account executive.

The conflict resolution question

Ask this first: "How do you handle write conflicts when two users edit the same record while both offline?"

This question has no generic answer. The right answer depends on the data type, the business rules, and what "winning" means for your operation. A vendor who has built this must choose a specific strategy and defend it.

Last-write-wins is the simplest approach. The most recent write overwrites earlier versions. It is appropriate when individual records are owned by one user and simultaneous edits are unlikely. It loses data silently when two users genuinely edit the same record.

Field-level merging is more accurate. Each field in the record is merged independently. If User A updates the status field and User B updates the notes field while both offline, both changes survive. It requires more complex implementation and does not work cleanly when two users update the same field.

Conflict queuing flags conflicts for manual resolution. When two offline versions of the same record diverge, the app marks the record as conflicted and presents both versions to a supervisor for resolution. It is the most accurate approach but requires UI for the conflict resolution workflow.

A vendor who answers "we sync the latest version" or "the server handles it" has not thought through conflict resolution. Those answers describe what happens after the conflict, not how the conflict is detected and resolved.

The background sync question

Ask: "What is your approach to background sync when the app is backgrounded on iOS?"

iOS has strict rules about what apps can do when they are not in the foreground. Background sync requires using specific iOS APIs (BGAppRefreshTask and BGProcessingTask) with a fetch interval controlled partly by the operating system, not just the app. Apps that have not implemented these APIs correctly will not sync in the background on iOS.

The correct answer describes the specific iOS background task API used, the fetch interval configured, how the app handles the case where the background task is killed before sync completes, and how the app retries incomplete syncs when it returns to the foreground.

An incorrect answer describes sync that runs "when the user opens the app." That is foreground sync, not background sync. It means a technician who completes five jobs and then does not open the app for two hours has five unsynced records that the back office cannot see.

On Android, the equivalent question is about WorkManager and the sync behavior when the device is in battery-saving mode. Android WorkManager has well-defined behavior in Doze mode. A vendor who has not implemented it correctly will give vague answers about "scheduling background work."

The storage and battery question

Ask: "How do you manage local storage as data volume grows, and what is the battery impact of background sync?"

Both questions reveal whether the vendor has shipped the app to a real field team for a real duration. An app that works well on day one of deployment may degrade over 90 days as local storage fills up and the sync queue grows.

Local storage management includes two concerns. The device has limited storage, and an app that grows its local database without pruning old records will eventually fill it. The vendor should describe their approach to local data retention: what stays on device, what is pruned after sync, and how the app handles a device that is running low on storage.

Battery impact is a common production failure that demos never reveal. Background sync that runs too frequently or does not respect iOS and Android power management APIs will drain the device battery noticeably. Field technicians using company devices for eight-hour shifts need the app to not be a significant battery drain. A vendor who has not measured battery impact in production conditions will not have an answer here.

The correct answer describes a sync frequency that is set based on data criticality (high-priority writes sync immediately on reconnection; lower-priority data syncs in batch), uses platform-appropriate power management APIs, and has been measured against real device usage patterns.

The MDM and device management question

Ask: "How does your app support MDM enrollment for enterprise device management?"

This question applies when your IT team manages the devices your field team uses. MDM-enrolled apps are distributed through managed app channels (Apple Business Manager or Google Play Managed), allow remote configuration, can be remotely wiped, and can enforce security policies at the app level.

The correct answer describes App Store distribution through Apple Business Manager or Google Play for Work, support for managed app configuration (setting environment variables through MDM without app updates), and any specific MDM platforms the vendor has tested against.

A vendor who has only distributed consumer apps will not have worked with managed distribution channels. Their answer will describe direct App Store download, which requires each technician to install the app manually and cannot be managed by IT.

For enterprise field apps managing sensitive data - job records, customer information, financial data - MDM enrollment is often a security requirement. A vendor who cannot support it is the wrong vendor for your operation regardless of their offline capability.

The production reference question

Ask: "Can you put me in contact with a client who is running your offline-first app for a field team that works in environments similar to mine?"

This is the final filter. Any vendor can describe offline architecture. A vendor with production references in real field environments - not office-based workflows, not controlled connectivity - has actually shipped the capability.

The reference call should cover four questions. How large is the field team? What connectivity environments do they work in regularly? Have there been data loss incidents since deployment? And would you choose this vendor again for a project requiring offline capability?

Red flags in the reference call: the reference mentions the offline capability is "being worked on" or "mostly functional," the field team is small (under 10 users in production), the connectivity environment is primarily Wi-Fi in controlled spaces, or the reference hesitates when asked about data integrity.

Full vendor scorecard

Use this scorecard in your live technical evaluation. Score each area 0-3 (0 = no answer, 1 = vague, 2 = specific but unverified, 3 = specific with production reference).

Question area	Score (0-3)	Notes
Conflict resolution strategy described with rationale
Specific iOS background task API named and explained
Android WorkManager behavior in Doze mode addressed
Local storage pruning approach described
Battery impact measured and manageable
MDM enrollment supported (Apple Business Manager / Google Play Managed)
Production reference in comparable field environment
Data loss incidents in production (0 = green)

A total score of 18-21 indicates a vendor with genuine production offline experience. A score below 12 indicates a vendor who is describing offline capability they have not delivered at enterprise scale.

How Wednesday answers these questions

Wednesday's answers to the scorecard questions above are specific because they come from production deployments.

Conflict resolution: Wednesday uses field-level merging for most enterprise field data models, with last-write-wins on status fields where the most recent state is always correct and conflict queuing for records where business rules require human resolution. The choice is documented in the architecture decision record for each engagement.

Background sync on iOS: Wednesday implements BGProcessingTask for bulk sync operations and BGAppRefreshTask for lightweight status checks. Sync frequency is set per data type based on criticality, with immediate sync for billing-critical records and batch sync for reference data.

MDM enrollment: Wednesday has distributed apps through Apple Business Manager and Google Play Managed for enterprise clients. Remote configuration through managed app configuration is supported in all enterprise builds.

Production references: Wednesday has shipped offline-first apps for a clinical health platform where zero patient logs were lost across the deployment, and for a logistics client managing field technicians across multiple service lines.

Those answers take under five minutes in a live call. If your current vendor cannot match that specificity, the scorecard has done its job.