Mobile

Offline-First Field Data Collection App

A survey and inspection app for people working where there is no signal: forms are defined server side, completed offline over days, and synced with proper conflict handling when a connection returns. Offline-first is a real architectural discipline and most student apps only pretend to do it.

Difficulty

Intermediate

A small team, or one strong student willing to learn something new.
Effort

1 semester, 2 students

Deliverables

5 to ship

3 optional extras

Suggested stack

FlutterSQLiteFastAPIPostgreSQL
A suggestion, not a requirement. Swap anything for what you already know.

What you should ship

  • Dynamic form renderer driven by a server defined schema, including photo, GPS and signature fields
  • Local storage with a durable queue of pending changes surviving app restarts and crashes
  • Sync engine with per record conflict detection and a defined resolution policy
  • Conflict resolution interface for the cases the policy cannot decide automatically
  • Demonstrated correctness under a test plan covering airplane mode, partial sync and interrupted uploads

If you have time left

  • Offline map tiles cached for the assigned survey area
  • Form versioning so submissions record which schema version produced them
  • Background sync when connectivity is detected without opening the app

The problem

Field work happens where the network is not. Health surveys, agricultural inspections, infrastructure audits and census work all involve people entering data for hours with no connectivity, and applications that assume a live connection lose that work.

What you build

A form engine driven by a server defined schema, a local store treated as the primary source of truth, and a sync engine that reconciles when a connection returns.

Why offline-first is genuinely hard

It inverts the normal design. The device is authoritative, the server is a replica, and every operation must be queued durably and be safely repeatable, because an upload can fail after the server processed it. Handling that without duplicating records is the core engineering problem.

The part to be rigorous about

Testing. Write an explicit test plan covering airplane mode mid submission, an app killed with a queue pending, the same record edited on two devices, and a sync interrupted halfway. Demonstrating those cases pass is a stronger result than any feature.

The design decision to defend

Your conflict policy. Last write wins is simple and loses data. Field level merge is better and more complex. Whichever you choose, state it and justify it, and provide a manual path for what it cannot resolve.

Scope warning

Do not build a form designer. A schema file, editable as JSON, is enough. The sync engine is the project.

Ideas and guidance, not finished projects

These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.

Not sure this one fits you?

I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.

Get guidance
Work with me

Stuck on something specific?

Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Every session is free; a few slots open each week.

Follow along

New writing, resources and project ideas land here first.