FieldFlow

Build and deploy offline-first workflows that keep hospitals, NGOs, and field teams operating without internet, then sync safely and prevent duplicate critical actions.

Comment

FieldFlow

Inspiration

I come from the eastern Democratic Republic of the Congo, where communities have lived through repeated humanitarian crises, displacement, insecurity, and unreliable access to essential services. In many places, the network is unstable or unavailable, but field teams are still expected to register families, coordinate assistance, manage supplies, verify cases, and make urgent decisions.

When connectivity disappears, many digital systems stop working at the exact moment they are needed most. Teams fall back to paper forms, spreadsheets, phone calls, or WhatsApp messages. The same information may be entered several times, delayed, lost, or duplicated. In field operations, that is not just a software inconvenience: it can mean one family is registered twice, medicine is allocated incorrectly, or decision-makers receive critical information too late.

That reality inspired FieldFlow: a platform for organizations that need field applications to keep working when the network cannot be trusted.

What it does

FieldFlow is an offline-first B2B platform for organizations running real-world field operations in low-connectivity environments.

Administrators can create operational workflows such as:

  • humanitarian beneficiary registration
  • food and non-food item distribution
  • patient intake and medical referrals
  • agricultural inspections
  • inventory and warehouse operations
  • community surveys
  • construction-site reporting

An administrator defines the forms, roles, approval stages, validation rules, permissions, and critical actions. FieldFlow turns that configuration into an installable Progressive Web App that workers can use on phones, tablets, or laptops.

Field workers can keep collecting data, capturing evidence, and completing assigned tasks while offline. Their work is stored locally on the device and synchronized when the network returns. Supervisors can review records, resolve conflicts, approve cases, and reserve inventory. Administrators can publish workflow versions and monitor how the operation is behaving.

The public demo is also database-backed. When a judge or visitor enters through demo mode, FieldFlow creates an isolated demo workspace for that visitor, seeds realistic organization data, and lets them test the product without creating an account. Their changes do not affect another visitor's demo session.

How we built it

FieldFlow is built as a full-stack application with a Next.js, React, and TypeScript frontend deployed on Vercel.

The frontend is a Progressive Web App. A Workbox-powered service worker caches the application shell, while IndexedDB stores workflow definitions, local records, pending operations, conflicts, and demo seed data on the device. This allows the app to remain useful even when the browser is offline.

Amazon DynamoDB is the primary backend database. We use it for organizations, users, workflow definitions, record projections, mutation history, device checkpoints, conflict records, inventory state, idempotency receipts, demo sandbox metrics, and audit/ledger entries. The data model is organization-scoped so each tenant, including each demo sandbox, has its own isolated workspace.

For synchronization, FieldFlow treats every local change as a traceable operation instead of blindly replacing an entire record. Each operation carries information such as the record ID, workflow version, base values, device, author, and sync status. If two devices edit different fields, the system can merge the changes. If they edit the same field differently, FieldFlow creates a clear conflict for supervisor review.

The sync layer is designed around idempotency. If a command is represented by (c), retrying the same command should not repeat the underlying business action:

$$ f(f(c)) = f(c) $$

That matters in unstable networks where a browser may send the same operation more than once.

For critical inventory reservations, FieldFlow uses DynamoDB transactions. A stock update, idempotency receipt, and ledger entry are committed together. If two workers try to reserve the final available item, conditional writes prevent double allocation. If a request is retried, the idempotency receipt prevents the same reservation from being applied twice.

Authentication uses Amazon Cognito for real users, with short-lived access cookies and longer-lived refresh cookies. Demo access is separate from real authentication and scoped to generated demo workspaces with DynamoDB TTL metadata for cleanup.

FieldFlow also includes an AI-assisted workflow generator. An administrator can describe an operation in normal language, and the system generates a draft workflow configuration for human review. AI helps with configuration; it does not make humanitarian eligibility decisions.

Challenges we ran into

The hardest part was not saving data offline. The hard part was making offline work safe once many devices reconnect.

We had to think through:

  • how to preserve local work when devices edit the same records
  • how to detect conflicts without hiding disagreements
  • how to make sync retries safe
  • how to keep workflow versions stable while records are being collected
  • how to separate ordinary offline data capture from critical actions like inventory reservation
  • how to keep demo workspaces isolated while still using the real database
  • how to protect tenant boundaries in every API path
  • how to make a complex distributed system understandable to nontechnical field users

Another challenge was balancing hackathon speed with production-oriented architecture. We wanted the demo to be easy for judges to try, but we did not want fake static data to be the core of the experience. The demo therefore creates database-backed sandboxes and loads data locally so visitors can still understand the offline-first product.

Accomplishments that we're proud of

We are proud that FieldFlow is not just a static prototype. It connects the frontend, authentication, offline storage, synchronization model, DynamoDB data model, demo sandboxing, and transactional inventory into one working product.

The most important accomplishments are:

  • A real offline-first PWA experience with local browser storage.
  • DynamoDB-backed organizations, workflows, records, inventory, conflicts, audit events, and demo sandboxes.
  • Isolated demo workspaces so judges can modify data without affecting each other.
  • Conflict-aware synchronization instead of silent last-write-wins data loss.
  • Transactional inventory reservation with idempotency receipts and ledger entries.
  • A visual workflow builder for forms, roles, states, transitions, permissions, and publication.
  • A multi-role demo experience for administrator, supervisor, and field-worker workflows.
  • A shippable architecture that can grow into a monetizable B2B product for field operations.

What we learned

We learned that offline-first software is an architectural decision, not a feature that can be added at the end. It changes the data model, API design, user interface, security model, retry behavior, audit history, and product experience.

We also learned that not every action needs the same consistency guarantee. A field observation can usually sync later. A conflict can be reviewed by a supervisor. But a final approval, voucher redemption, or last inventory reservation needs stricter protection. DynamoDB gave us a practical way to combine high-volume operational sync with conditional and transactional writes for critical paths.

Finally, we learned that a demo can be more than a shortcut around signup. For FieldFlow, the demo became part of the technical story: a generated, tenant-isolated, DynamoDB-backed sandbox that lets people experience the real product safely.

What's next for FieldFlow

Next, we want to expand FieldFlow from a hackathon product into a field-operations platform that organizations can deploy quickly.

The next priorities are:

  • stronger workflow version migration tools
  • richer conflict-resolution policies by field type and role
  • encrypted local storage for sensitive offline records
  • attachment sync for photos and documents
  • organization analytics for sync health, device health, and operational bottlenecks
  • deeper AI-assisted workflow generation with human approval gates
  • template libraries for humanitarian aid, health outreach, logistics, agriculture, and construction
  • production-grade onboarding, billing, and organization administration

The long-term vision is simple: teams should not have to stop serving communities just because the network disappears.

Built With

Share this project:

Updates