Berke Özyaşar
Blog

An offline-first construction app: how we designed Şantiyepro

How do you design an app that works on construction sites with no internet? Notes on offline-first architecture, sync and testing from Şantiyepro and its 56 modules.

·
Şantiyepro website homepage

Şantiyepro is a construction site management app for the construction industry that we develop as our own product. It has 56 modules, from timesheets to cash and current accounts, from work progress records to progress payments, concrete tracking and occupational health and safety (OHS); it runs on Android and iOS, and there is also a WebPanel for desktop access. The product's defining feature, though, is that it works completely offline. I am Berke Özyaşar, and in this post I explain the reasons behind that decision and what to watch out for when building an offline-first app.

On a construction site, internet is not a given

For software used in an office, an internet connection is almost always there. A construction site is different. In basements, between reinforced concrete shear walls, on land outside the city or in newly developed areas, mobile data is weak or nonexistent. If a foreman wants to enter the day's timesheet at the end of the day and the app shows a "connection error," that record either goes back to paper or never gets entered. This is one of the most common reasons field apps go unused.

That is why the core principle in Şantiyepro is this: the app works fully without needing the internet, and data is stored on the phone first. You do not need a connection to enter records, generate reports or look back at history. Role-based cloud sync comes into play when the team needs to work together.

Offline-first vs. "offline support"

Many apps offer "offline support": when the connection drops, they show the last data they saw and maybe queue a few actions. Offline-first assumes the opposite: the app's primary data source is the local database on the device, and the server is a sync target. This difference affects every layer of the architecture:

  • Screens read from the local database, not the network, so they open at the same speed whether there is a connection or not.
  • Every record is valid the moment it is created on the device; it does not wait for the server's confirmation.
  • Record IDs must be generated uniquely on the device without asking the server; otherwise records created on two devices at the same time will collide.
  • Reports and calculations, such as a timesheet summary or a cash balance, must be possible on the device.

Sync: the hard part

Having the data on the phone is enough for a single user. But when the site manager, the technical office and accounting want to see the same data, you need sync. Questions to answer when designing sync in an offline-first system:

  • What gets sent? You need to track which records have changed since the last sync. Marking every change with a timestamp or version number means only the difference gets sent.
  • What happens in a conflict? If two people change the same record while offline, which one wins? For many record types, last write wins is enough. But for financial records such as cash and current account transactions, adding a new transaction instead of changing the existing record is much safer; that way you get two separate records instead of a conflict, and the balance can always be recalculated from the transactions.
  • Who sees what? In Şantiyepro, sync is role-based. A foreman and the company owner do not see the same data; each device should receive only the data that user is authorized to see.
  • How do deletions propagate? For a record deleted on an offline device to be deleted on other devices too, it needs to be marked as deleted rather than physically removed.
  • Large files: Photos in work progress records are much larger than text data. Sending them in a separate queue when the connection allows keeps them from holding up record sync.

Trust in the field: signature, location and time

On a construction site, when and where records were entered matters; a site report, a delivery note or an OHS inspection should not become a point of dispute later. In Şantiyepro, digital signatures are recorded together with GPS coordinates and a timestamp. Working offline adds a subtlety here: location can be taken from the phone's GPS without internet, but the device clock can be changed by the user. For records like these, storing the server time at sync alongside the device time is useful for any later checks.

Keeping 56 modules manageable

Timesheets, cash, current accounts, check tracking, work progress, internal shipments, concrete pour and rebar tracking, purchasing, progress payments, quality control, OHS... Şantiyepro's scope is broad because work on a construction site is not disconnected. In a product this broad, having every module behave like a standalone app would make maintenance impossible. The modules need to share a common foundation: the same local data layer, the same sync logic, the same permission model, the same reporting and export tools. That way, adding a new module is not writing a feature from scratch but adding a new data type and screens on top of that foundation.

The product's users are varied too: contractors, home builders, engineers, OHS specialists, technicians and foremen. Each of them uses a different part of the app heavily. Keeping the menus and home screen simple according to role and need is important so that 56 modules do not overwhelm the user.

Testing: airplane mode is your best friend

The most effective way to test an offline-first app is to actually use it without a connection. The test list for an app like this should always include:

  • Entering records in airplane mode for a whole day, then turning the connection on and watching the sync
  • Changing the same record offline on two devices and checking the conflict behavior
  • Cutting the connection halfway through a sync and checking whether the data stays consistent
  • Updating the app and verifying that schema changes in the local database are applied without corrupting existing data
  • Measuring performance on older, low-storage devices with large numbers of records and photos

The last item is especially important: Şantiyepro supports Android 8.0 and above, and not every phone used in the field is a new model.

Keeping data with the user

The offline-first approach has a non-technical benefit as well: data stays on the user's phone. Site cash, subcontractor payments and current accounts are sensitive information. Şantiyepro's free plan lets you start with a single construction site, and cloud sync comes into play when the team wants to work together. This makes the product usable both for small contractors working alone and for large teams.

Releases and the update cycle

Şantiyepro is live on Google Play and the App Store. We update the product on a release cycle of about 45 days. In an offline-first app, every release has to migrate the existing data on the device safely, so a regular and predictable rhythm matters.

Conclusion

If you are building software for people who work in the field, you need to treat an internet connection as a bonus, not an assumption. Offline-first architecture takes more design effort, but it gives users a tool that works in any conditions. If you are considering a similar field app or SaaS product, you can see how I work on the SaaS product development and mobile app development pages.

More articles

Let's ship your app together.

Describe what you want to build in a few sentences. I reply the same day.

Use ↑ ↓ to navigate, Enter to open, Esc to close