Local-first as a legal position, not a technical choice
Building an application without servers changes the provider's GDPR profile in ways that few Italian vendors grasp. One exits the data processor qualification under Art. 28 and enters the lighter category of software provider.
The difference that changes everything
Art. 28 of the GDPR defines the "data processor" as the entity that processes personal data on behalf of the controller. From this qualification flows a non-trivial cascade of contractual, organisational, and insurance obligations: formal appointment, detailed Art. 28 contract, records of processing activities, periodic audits, data breach notification, joint and several liability with the controller toward data subjects, and so on.
EDPB Guidelines 07/2020 ("Guidelines on the concepts of controller and processor in the GDPR") clarify at § 30 a point that Italian practice has systematically underestimated: the mere software provider that does not access data and does not process data on the client's behalf is not a data processor. It is a provider. Full stop.
Why the distinction matters
For an Italian software provider, the difference between "data processor" and "software provider that does not process" translates into:
— Dramatic reduction of insurance risk (joint and several liability toward data subjects disappears)
— Disappearance of the Art. 28 appointment requirement on the client side (contractual simplification)
— Elimination of the need for a dedicated DPO on the provider side in almost all cases
— Drastic reduction of the perimeter of a potential data breach (the provider does not hold the data, therefore cannot notify a breach it does not have)
How to build a credible local-first position
Declaring "local-first" in marketing is not enough. The position is defensible only if the architecture is technically verifiable by a client's consultant in a few minutes.
First requirement: no provider-managed server endpoint should receive personal data. All network flows depart from the client's device and arrive directly at the institutional destination (e.g. Sistema TS, Alloggiati Web). Verifiable via browser DevTools — Network panel.
Second requirement: storage is exclusively client-side, in browser IndexedDB, with at-rest encryption derived from user PIN. Sensitive credentials (e.g. Sistema TS password) are encrypted before being persisted. Verifiable via DevTools — Application/Storage panel.
Third requirement: no analytics or telemetry sending identifiable data. Plausible or cookie-less aggregate analytics yes; Google Analytics or Mixpanel no.
Fourth requirement: the code executed on the device is readable (not aggressively obfuscated, source maps available on request). This permits independent audit by a client's consultant.
The cloud sync trap
The biggest temptation, after building local-first, is to introduce "cloud sync" for multi-device backup. It is a rational temptation from a product standpoint and a catastrophe from a legal standpoint, because it relocates the provider into the role of data processor for the data transiting through the sync.
The solution, if sync is really necessary, is the E2E encrypted blob pattern: the client's device encrypts the entire database with a key derived from the client's passphrase, and uploads the encrypted blob to object storage (Cloudflare R2, Backblaze B2, S3) operated by the provider. The provider holds the blob but cannot read it. The key is only on the device.
This configuration maintains the "software provider" position: the encrypted blob is not "identifiable personal data" under the GDPR for the provider, because the provider does not hold the key. For the client it is — but the client is the controller anyway. All in order.
Contractual implications
See the DPA published on our website: it explicitly declares the absence of the data processor role, founds the position on local-first architecture, leaves all GDPR obligations with the client as controller. A diligent client willingly accepts it, because the advantage in terms of contractual speed and reduced insurance costs is significant.
An unsophisticated client sometimes asks to appoint the provider as a processor "to be safe". They must be educated: a superfluous appointment introduces disproportionate obligations for both parties. It is contractual sloppiness, not prudence.