Skip to main content

Prompt: Design an Offline-First Field App

Prompt​

Design a frontend architecture for field workers who inspect sites with unreliable connectivity. Users must capture notes, photos, checklist items, signatures, and submit reports when back online.

Clarifying questions​

  • Which data must be available offline?
  • Which actions can conflict?
  • What data is sensitive on device?
  • What happens when sync partially succeeds?
  • What device/storage limits matter?

Model answer outline​

  • App shell and required reference data available offline.
  • Local draft store with explicit sync queue.
  • Conflict policy by entity type.
  • Background sync if available, manual sync fallback.
  • Clear pending, synced, failed, and conflict states.
  • Sensitive data minimization and storage expiry.
  • Observability for queue depth, sync failures, conflict rate, and data loss.

Architecture diagram​

Weak answers​

  • Assumes network calls will retry invisibly.
  • No conflict policy.
  • Stores sensitive data indefinitely.
  • Sync failures only show generic toast.
  • No way to inspect pending work.

Scoring​

Strong answer: offline data model, sync queue, conflict rules, sensitive storage policy, status UI, retry/idempotency, and operational metrics.

For a complete calibrated answer, read worked-answer-offline-first-field-app and compare it with part-iii/local-first-sync-collaboration.