A project coordinator edits a shared work pack on a train between two Finnish customer sites. The application saves instantly, even through a tunnel. While the coordinator is disconnected, an administrator removes their access to that project. Thirty minutes later the laptop reconnects with a queue of useful changes.
Should those edits join the shared document? Should they remain available only to the author? Can a manager review and accept selected material? And what happens to project information already stored on the laptop?
These are product decisions behind local-first software. Fast editing and offline availability are attractive, but the commercial value depends on how the application handles the moments when collaboration and authority diverge.
What local-first technology changes
Automerge describes local-first software as treating the user's device copy as primary while enabling offline work, collaboration and synchronisation. Its document model supports merging changes rather than requiring every interaction to wait for a central server. Automerge introduction
The project's tutorial also shows separate storage and network adapters, including browser storage and synchronisation between local tabs. That separation is a useful architectural reminder: persisting an edit locally and sharing it with authorised collaborators are different operations. Automerge storage and sync tutorial
The wider local-first approach is explored by Ink & Switch. It provides a design perspective on responsive tools and user ownership, rather than a ready-made access-control policy for your organisation. Ink & Switch local-first research
Choose which work deserves to be local
A useful starting point is to classify operations by consequence. Drafting notes, arranging tasks and annotating a plan may benefit from immediate local changes. Approving a payment, granting access or publishing a contractual commitment often needs a central authority to accept a deliberate transition.
That does not make the second group impossible offline. It means the product must describe the action honestly as a prepared request until the authoritative system accepts it. The user should see the difference between saved on this device, shared with the team and approved for execution.
For the Finnish work-pack example, a technician can prepare observations without connectivity. The final release of instructions to a subcontractor can remain a separate, authorised step. This gives the field team a practical benefit without pretending that network absence removes the business's approval rules.
Design for revocation before the first customer rollout
Revocation has at least two meanings: stopping future synchronisation and controlling information already available on a device. The first can be enforced when the device contacts an authority. The second cannot be guaranteed merely by removing an account while the device is offline.
Decide what the application is permitted to download, how much history it keeps and which devices are eligible. Sensitive projects may need tighter local retention or a different workflow. Device management and encryption can contribute to a broader control model, but a product should not promise remote erasure of every prior copy.
On reconnect, check current permission before accepting changes into shared state. Do not rely on a client-provided timestamp as proof that an edit was made before access ended. If historical eligibility matters, design an evidence model with the responsible security team rather than trusting the laptop's clock.
Give rejected edits somewhere understandable to go
Silently dropping offline work is a terrible user experience. Silently accepting it after revocation can be a serious authorisation failure. A clear rejected or pending-review state can preserve work without granting the author the power to alter the shared project.
Define who can review that material and whether local export is allowed under the product's data policy. The application should explain why synchronisation stopped and what the user can do next. It should not expose information from the current project while displaying the rejection message.
An administrator also needs a view of unfinished activity. Otherwise the organisation may discover important observations only when a former team member asks why the work disappeared. This is a workflow design problem that a merge algorithm cannot answer on its own.
A successful merge can still be the wrong business result
Two people can independently edit different fields and produce a technically mergeable document that violates a business rule. One changes the work location while another approves a risk assessment for the previous location. Both edits are valid in isolation; their combination requires review.
Use explicit revisions for approvals and show when supporting content changes after approval. Keep authority-bearing transitions separate from free editing where appropriate. The interface should indicate that an approval applies to a particular revision rather than to whatever the document happens to contain now.
Our guide to customer portal security requirements helps frame those boundaries. The article on software acceptance evidence explains how to turn them into a delivery agreement.
Test reconnect behaviour with people, not only replicas
The pilot should include a real user explaining what they believe has happened after each state change. Technical convergence tests are valuable, but they do not reveal whether the product language makes an unshared draft look like a completed team action.
- ▸Edit on two devices while one remains offline.
- ▸Revoke a project permission before the disconnected device returns.
- ▸Change the business state while an older local draft still exists.
- ▸Fill or deny local storage and show a comprehensible recovery path.
- ▸Reconnect after the application has deployed a new data-model version.
Measure how much work users complete without waiting, how often manual resolution is needed and whether support can explain a rejected change. These are more useful buying metrics than the number of edits a demo can merge per second.
Scope a bounded collaboration product
Begin with one work pack, one user group and one offline scenario that currently causes delay. Agree the local-data policy, document boundaries, approval transitions and handover responsibilities before expanding to the whole organisation.
If you are evaluating who should build the product, Anis Khalef's selected software work offers a starting point for discussing product scope and delivery. Ask separately for a demonstration of the offline and permission behaviour your project requires.
TuniCyberLabs can help turn that brief into custom software development with a testable collaboration model. Discuss an offline collaboration pilot and bring the last real situation in which connectivity prevented useful work. The strongest design starts with that situation and the authority rules around it.