Offline-First Field Data Platform

Business context

A research-focused organization runs a platform that field participants use to record geo-located environmental observations: species sightings, site measurements, photos, and structured survey data. The quality and completeness of that data is the heart of the organization's mission.

Different research projects run on the same platform, each with its own data needs and its own set of contributors, from volunteers in the field to staff administrators.

The problem

The people who matter most, the researchers collecting data, work in remote locations with poor or no connectivity. The existing platform assumed a stable connection and broke down without one, so observations could not be reliably captured in exactly the conditions where the work happens. That put real field data at risk.

At the same time, the platform had grown hard to evolve. Its structure made it difficult to scale and change safely, and parts of an older system were still relied on, which slowed progress and added risk.

Our solution

We led both the strategy and the build. The priority was making the platform genuinely dependable in the field, held to a production-quality bar rather than treated as a nice-to-have.

In parallel, we modernized the underlying architecture in a way that protected the existing experience, so nothing that already worked was put at risk during the change.

• Reliable offline data capture, so researchers can record observations with no connection and have them sync automatically once they are back online.
• A connection-aware experience that clearly shows what is saved, what is pending, and what needs a network, so field users always trust the system.
• Dependable sync that preserves the right order on reconnect, so related records are never lost or left orphaned.
• A cleaner separation between the web experience and the data service, giving the platform room to scale and evolve, with strong isolation between projects.

The outcome

Field participants can now collect and queue observations with no connectivity and sync them later, directly removing the platform's most field-critical limitation and protecting the data the mission depends on.

The organization also gained a cleaner, more scalable architecture and a better-structured codebase, making the platform easier and safer to grow.

Technology

The technology choices were driven by the realities of field research: unreliable networks, multiple projects, and data that cannot be lost.

• Data integrity: offline observations are captured and held safely on the device, then synced in dependency-aware order on reconnect, so records are never lost or orphaned, which is the central guarantee the mission depends on.
• Data architecture and isolation: a dedicated Python service (built on Starlette) separates data concerns from the web tier, with per-project isolation that keeps each research project's data cleanly separated in a multi-tenant model.
• Cloud and infrastructure: a cloud-native deployment on AWS, with the web tier and the data service hosted and scaled independently and managed data services for durability.
• Resilience and availability: an offline-first Progressive Web App keeps the platform usable with no connectivity, exactly where the work happens, with a connection-aware experience that always shows what is saved and what is pending.
• Scalability: separating the web experience from the data service lets each scale and evolve independently as more projects and contributors come on board.
• Quality and reliability: layered automated testing, including cross-browser and mobile coverage of the critical field flows, holds the experience to a production-quality bar.
• Core stack: Next.js and React on the frontend, Python and Starlette on the backend, with PostgreSQL and SQLite for durable, isolated data.