In many of the communities where we work, reliable internet access cannot be taken for granted. Connections drop mid-task. Pages stall without warning. Data is expensive, and in many areas, coverage simply doesn’t reach.

Here’s what that looks like in practice: in parts of Madagascar, just establishing a connection can take 3 to 4 seconds, and that’s before any data even starts moving. A 200 KB file, smaller than a single photo, can fail partway through and need several retries. What should take a second or two can end up taking 40 seconds or more, with the app appearing stuck the whole time. For a health worker logging a patient visit before moving to the next village, a wait like that isn’t a minor inconvenience. It can mean a record is delayed, interrupted, or never saved.

This happened often enough that it shaped how we decided to build our product. Our team was spending real time and energy on dropped connections, retried uploads, and figuring out why a sync had failed. That was time that wasn’t going toward anything a health worker or patient would actually notice. So instead of asking “how do we cope without the internet?”, we asked “what if the app didn’t need the internet to work at all?” That question led us to what’s called a local-first approach.

In plain terms, local-first means:

• Your data lives on your device first. Your phone or laptop isn’t just a screen waiting for instructions from a server somewhere, it holds everything it needs to work on its own.
• Going online is a bonus, not a requirement. The app works fully offline. When a connection does show up, it quietly catches up and shares updates in the background.
• The experience stays smooth. No spinning wheels, no “please try again” messages, no lost work. The app responds instantly, because it isn’t waiting on a network.

We didn’t want to reinvent the wheel to get there. Rather than build a syncing engine from scratch, we chose to build on RxDB, an established open-source local-first database.

What local-first changed for us

Building this way changed both how we work and how people experience our product.

It builds trust. We’re no longer “the app that breaks when the signal drops.” People can rely on it.

It freed up our team. Instead of repeatedly troubleshooting failed uploads and unstable network behavior, our team could focus more on improving the product itself: clearer interfaces, more useful insights, and a better understanding of what users actually need.

Building for real-world conditions 

For anyone building technology that needs to work in rural and low-connectivity settings, choosing to design this way is more than a technical decision. It means designing around the conditions in which people actually work, rather than assuming reliable connectivity will always be available.

That matters across the settings in which Elucid operates, from Madagascar and Uganda to Ecuador and Ghana. Different contexts bring different constraints, but the underlying principle is the same: the technology should continue to support people even when the network cannot.

For us, local-first architecture is therefore not primarily about following a software trend. It is about making sure a health worker can complete a task whether they have strong connectivity, intermittent signal, or no connection at all.

When software is built for the conditions in which it will actually be used, reliability stops being an extra feature. It becomes part of the product itself.