Most web apps are optimized for the happy path: fast internet, reliable servers, users sitting at their desks. But the real world looks different. Field technicians in basements. Property managers in underground parking garages. Service workers on remote sites. For these users, "your connection was lost — please try again" is not an acceptable error message.
This is why we built smallstack on a local-first architecture. Here's what that actually means in practice.
Local-First vs. "Offline Mode"
"Offline mode" is what most apps call it when they let you view cached content without an internet connection. You can browse — but the moment you try to save something, you hit a wall.
Local-first is different in a fundamental way: the local device is the primary storage location. The app reads from and writes to local storage first. The server is a sync partner, not the single source of truth.
The practical difference:
- Offline mode: read-only without connection
- Local-first: full read/write without connection, automatic sync when reconnected
How Incremental Sync Works
The challenge with local-first isn't the offline part — that's straightforward. The hard part is sync: how do you reconcile changes made by multiple users who were offline at the same time?
smallstack uses SignalDB for incremental sync. The key design decision: instead of syncing entire collections, we sync only the deltas — changes since the last known sync point. Each change carries a timestamp. On reconnect, the sync protocol exchanges only what changed since the last successful sync.
This approach has several practical advantages:
- Minimal bandwidth — particularly important for users on mobile connections
- Fast reconnect — syncing 50 changed records is much faster than re-downloading thousands
- Real-time propagation — changes from one user appear at other clients within seconds of reconnecting
Conflict Resolution
When two users edit the same field while offline, you have a conflict. Our approach for most cases is last-write-wins with timestamp ordering. The most recent change (by device clock) wins.
This covers the majority of real-world cases. For more complex scenarios — like numeric counters that both users incremented — the data model can define merge strategies. The goal is predictable behavior that teams can reason about, not invisible magic.
A Real Scenario: Field Service Inspection
Here's a concrete example of how this plays out:
A service technician arrives at an industrial site with no mobile coverage. They open the smallstack PWA (installed from browser — no app store needed). The app loads with all their assigned tasks already cached from the last sync.
They complete three inspections, attach photos, add notes. All changes are written to local IndexedDB immediately — no spinners, no "saving..." indicators. The UI is instant.
An hour later, back in the parking lot with signal, the app reconnects. SignalDB runs the incremental sync: the three new inspection records and their attached file references are pushed to the server. Within seconds, the office team can see the completed inspections on their dashboard.
No manual "sync now" button. No lost data. No double-entry.
Why This Architecture Matters for Business Apps
For consumer apps, offline support is a nice-to-have. For business-critical workflows, it's different: if your team can't record data, they either lose it or work around your tools. Both outcomes are bad.
Local-first removes this failure mode entirely. The app works regardless of connection state. This makes it genuinely suitable for:
- Field service teams working in buildings with poor coverage
- Trades and construction where sites often have no reliable WiFi
- Property management — inspections, maintenance logs, tenant records
- Any team that needs reliability over SaaS uptime dependence
The Performance Bonus
Offline capability is the headline, but local-first has a performance side effect that benefits everyone — including users who are always online.
When data lives locally, read operations are instant. Filtering a list of 5,000 records? No network round-trip. The UI is as fast as the local machine, not as fast as the network.
This changes how you can design UIs. You can afford live filtering, real-time search, and reactive dashboards without debouncing every keystroke or showing skeleton loaders everywhere.
Try It Yourself
smallstack ships this local-first architecture as part of its no-code platform — you get offline capability and real-time sync without writing a line of sync code yourself. The widget-based app builder sits on top of this foundation.
If you want to dig deeper into the technical side, check out the smallstack documentation or try building a simple app on the free tier to see the sync behavior in action on smallstack.com
Building something local-first? Have questions about the sync approach? Drop a comment — happy to get into the details.
Top comments (0)