In our previous article, we explained when offline mode is actually needed and how much it costs to implement. The topic came up far more often than we expected, so it’s time to move from theory to practice. In this article, we’re sharing a real project from our portfolio, a typical fieldwork scenario, and the key lessons we’ve learned about data synchronization after delivering several offline-enabled applications.
Case Study: A Mobile App for Field Sales Representatives
One of the projects where offline mode wasn’t just a nice-to-have but an essential requirement was a mobile application extending the client’s CRM system to support their sales team. The app was designed to give sales representatives quick access to customer information, contact history, and the ability to plan and report visits directly from their smartphones.
The challenge became obvious very quickly. Sales representatives spend most of their time in the field, often visiting customers located in places with poor or unstable internet coverage—warehouses, production facilities, or smaller towns. An application that stops working without an internet connection simply isn’t practical in this environment.
We had to design a mechanism that would allow users to:
- continue working without an internet connection by adding notes, photos, and visit statuses,
- securely store all collected data locally,
- automatically synchronize it with the CRM system as soon as the device reconnects to the network,
- do all of this without data loss or duplicate records.
The biggest challenge wasn’t storing data offline—that part is relatively straightforward. The real complexity came with two-way synchronization. Data entered in the mobile app had to appear in the web application almost immediately, and vice versa, without creating conflicts when both a field representative and an office employee updated the same customer record at the same time.
It’s also worth mentioning that GPS data collected while offline isn’t only used to confirm customer visits. In this type of application, the location of field representatives or service employees is often used later to calculate bonuses and payroll. The system therefore has to record the exact time and location of each visit even without network coverage, and then reliably synchronize this information for payroll processing without delays or the possibility of users modifying or omitting the data. This significantly raises the bar—offline GPS data must be treated with the same level of reliability as information transmitted in real time.
Another Common Scenario: Field Data Collection and Documentation
Beyond this project, offline functionality regularly comes up in conversations with clients from entirely different industries, including logistics, technical services, inspections, and field data collection. Interestingly, the underlying problem is almost always the same, so we’ll describe the scenario without referring to any specific client.
A typical case looks like this: a field worker needs to complete a form, take a photo, scan a barcode, or record GPS coordinates—but they’re working somewhere without internet access, such as a basement, an industrial site, or a remote road outside the city.
The solution that consistently works in practice includes:
- a local task queue, where every user action (forms, photos, scans) is first stored in a local database on the device,
- automatic background synchronization as soon as an internet connection becomes available,
- a clear interface indicating which data is still waiting to be synchronized and which has already reached the server,
- an automatic retry mechanism for unstable connections instead of failing after a single unsuccessful upload attempt.
Without this kind of architecture, field workers either lose their data or—perhaps even worse—stop trusting the application altogether and go back to using notebooks or Excel spreadsheets. This is one of the most common reasons clients approach us about implementing offline mode in the first place.
A Third Example: Downloading Video Content for Offline Viewing
Offline functionality isn’t always about fieldwork. Sometimes it’s simply about allowing users to access content without an internet connection.
That was the case in a project involving a video streaming application with Polish Sign Language interpretation. Users needed to be able to download videos and watch them later, even when offline. This was a key accessibility feature, since a reliable internet connection isn’t always available where users actually want to watch the content.
The challenge wasn’t downloading the videos themselves, but what happens when the user closes the application while a download is still in progress. Without the right mechanisms, this resulted in corrupted or incomplete files that couldn’t be played after reopening the app, often forcing users to start the download from scratch.
To solve this, we implemented:
- resumable downloads that continue from the interruption point rather than restarting,
- background downloading while the application is minimized,
- automatic detection and cleanup of incomplete or corrupted files, ensuring users never attempt to play damaged content,
- clear progress indicators showing whether a video is ready for offline viewing.
This is a good example of how offline functionality isn’t always about synchronizing forms or business data. Sometimes it’s equally demanding because of the complexities involved in managing files directly on the device.
What We’ve Learned About Data Synchronization
After delivering several offline-enabled applications, we’ve noticed that the same conclusions apply regardless of the industry.
Data conflicts should be anticipated, not patched later. Before writing a single line of code, we work with the client to define clear conflict-resolution rules. Should the latest change win? Should records be merged? Or should users be asked to resolve conflicts manually? Skipping this decision at the beginning almost always leads to significant redesigns halfway through the project.
Offline testing must reflect real-world conditions—not just airplane mode. Unstable connections, interrupted uploads, and switching between Wi-Fi and mobile networks are the scenarios most likely to break synchronization in production, yet they’re often overlooked during testing.
Local data storage is a security concern, not just a performance optimization. Customer information and field documentation stored on a device must be properly encrypted, especially considering that mobile devices can be lost or stolen.
What Does It Cost in Practice?
In our previous article, we mentioned that adding offline functionality typically increases the project budget by 30–50% compared to an application that always requires an internet connection.
Our experience from real-world implementations confirms this estimate. The biggest cost increase doesn’t come from storing data locally—it comes from designing synchronization logic and handling data conflicts reliably.
That’s why we always recommend defining exactly which features truly need to work offline during the planning phase. In many cases, limiting offline functionality to the critical workflows significantly reduces both development costs and project complexity without compromising the user experience.
How We Approach Offline Projects
Before we start designing an offline architecture, we ask our clients a few key questions:
- Where do users actually work, and how often do they lose internet access?
- Which actions are mission-critical and must work offline?
- Which features can safely wait until the connection is restored?
- What should happen if two users modify the same data simultaneously?
The answers to these questions shape the entire architecture of the solution and help avoid building offline functionality where it simply isn’t needed.
If your users work in the field, operate in areas with unreliable internet access, or you suspect that the lack of offline support is causing abandoned forms or frustrated users, we’d be happy to help. Get in touch with us, and we’ll review your specific case, honestly assess whether offline mode is the right solution, and estimate what such an implementation would realistically cost.
