A desktop engine where data never leaves the device
Law firms, medical-travel agencies, accounting offices — most small firms holding sensitive data still run on spreadsheets. What stops them moving to cloud software is not price; it is the question of where the data goes. This engine exists to remove that question.
What was the problem?
Small firms holding sensitive personal data struggle to adopt cloud software because there is no clear answer to where the data goes and who can reach it. Spreadsheets appear to avoid the question, but they create others: version confusion, five copies of the same file, and changes nobody can audit.
The engine opens a third path: read the structure already expressed in the spreadsheet, turn it into an installable desktop application, and keep the data on the device. Nothing is sent to a cloud service, so there is no cross-border transfer to account for.
Architecture decisions and why
The application runs on Tauri 2 with an Angular interface and stores data in an embedded SQLite file bundled with the application. The user does not install a database. Every decision was made against one criterion: the fewer steps the installation takes, the more the target user will actually use it.
| Decision area | Choice | Reason |
|---|---|---|
| Application shell | Tauri 2 · Rust | Small installer, close integration with the OS, no heavy browser engine bundled. |
| Interface | Angular | Reuse of an existing component base; one language across web and desktop. |
| Data | Embedded SQLite | A single file; backup is comprehensible to the user — copy the file. |
| Identifiers | UUID primary keys | Prevents collisions up front if device-to-device sync is added later. |
| Deletion | Soft delete | Keeps an audit trail; irreversible deletion is a poor default for sensitive data. |
| Process boundary | Coarse-grained semantic calls | Meaningful operations instead of per-field calls keeps the surface area small. |
What does local-first change about data residency?
In an architecture where data never leaves the device, no cross-border transfer takes place, so the obligations attached to transfer do not arise. The data controller’s duties do not disappear, but the surface area shrinks: the question stops being “where does the provider process this” and becomes “who holds this device and how is it protected”.
This is an architectural observation, not legal advice. Assessing regulatory obligations is a lawyer’s job; mine is to build the architecture so that assessment is simple.
Why documentation is part of the product
The first output of development was not code but a 39-file documentation package: end-user documentation, a project rules file, repeatable development workflows, and test fixtures for the first phase. The reason: in a local-first product nobody is standing behind it to provide support, so the product has to explain itself.
- Documentation written for the end user, not the developer.
- A project rules file: invariants, version dependencies and architectural constraints in writing.
- Repeatable workflows for adding a field, a screen or a migration.
- Realistic test fixtures for the first phase — no assumption can be tested in an empty application.
Current status
The engine is in development; there is no released version. This page describes how a product where data does not leave the device is built, not a finished product. The same architectural decisions are reused in client projects for modules holding sensitive data.
Last updated: