ImplementedWindows desktop platform

TAMS — Offline-first travel-agency platform

Desktop platform implemented · cloud control plane partially built

A Windows back-office platform designed for travel agencies that must keep working when the internet does not. The system combines local-first data, a secure LAN deployment mode, bilingual workflows, and recovery-aware operations.

Role: Co-founder · Technical lead
Dates: Jun 2026 – present
Source: Private — case study only

01 · Context

The problem

Travel agencies run bookings, invoicing and customer files from counter PCs, often on an unreliable connection. The back office has to keep trading when the internet is down, grow from one PC to several desks sharing one set of books, and be installed, updated and recovered by people who are not IT staff.

Constraints

Trading must continue with no internet connection.
Several desks in one office must share one database — and SQLite on a network file share is not safe.
The database on the agency PC is the customer's only copy of their data.
Installs, updates and recovery have to be safe by default for non-technical users.
French- and English-speaking users work in the same product.

02 · Ownership

What I owned

Co-founded the product with a travel-agency owner: gathered the requirements from how an agency actually works, and designed the application around them.
Built the MVP alone: the core back office for customers, reservations, invoices, payments, treasury and reports.
Run the development process: write the backlog tickets, plan the releases and set the order of work.
Handle deployment: install and update the application at the pilot agency, following written installation, update-rehearsal and recovery runbooks.
Architected the local, server and client run modes that let one installer scale from a single PC to a multi-desk office.
Implemented server-side authorization as a single fail-closed channel policy table, verified in CI.
Designed the LAN transport: HTTPS between desks and the office server, with trust-on-first-use certificate pinning.
Built the release path: signed update manifests, compatibility gates, pre-migration backups and a LAN update relay.
Delivered the bilingual French/English interface and wrote the architecture decision records and backup, recovery and incident-response procedures.

03 · Architecture

System at a glance

Deployment modes and data boundaries

Implemented
Partially built
Designed

Agency desks

Standalone PC
Local mode
Status: Implemented.
Office desks
Client mode — no local database
Status: Implemented.

Office server

Server mode
Same handlers over pinned HTTPS
Status: Implemented.
Channel policy table
Fail-closed authorization
Status: Implemented.

Data

SQLite master record
One database per agency
Status: Implemented.
Pre-migration backups
Taken before every schema change
Status: Implemented.

Cloud control plane

Signed update feed
Outbound only
Status: Partially built.
Licensing lease
Offline grace period
Status: Designed.
Fleet monitoring & sync
Derived facts only
Status: Designed.

One Windows installer runs in three modes. On a single PC, local mode owns its own SQLite database. In an office, one PC runs in server mode and owns the database, while the other desks run in client mode and call the same handlers over HTTPS with a pinned certificate. Cloud services for updates, licensing and fleet visibility sit outside the office and are designed to be reached by outbound requests only: the signed update feed is partially built, while licensing and fleet sync are designed but not built.

How the pieces connect

A standalone PC reads and writes its own SQLite database in local mode.
Office desks in client mode send every call to the office server over HTTPS, trusting only the certificate fingerprint pinned on first connection.
The office server owns the SQLite master record and takes a backup immediately before any migration.
The office server relays verified update packages to its desks, updating the desks first and itself last.
Desks and servers contact the cloud control plane with outbound requests only; the cloud never writes operational data.

Stack

Electron
React
TypeScript
Node.js
SQLite
i18next
HTTPS / TLS
NSIS installers

04 · Decisions

Engineering decisions

Each decision is written as the constraint that forced it, the choice made, the cost accepted, and what it bought.

D01
The local database is the master record
Constraint
Agencies must keep selling during an outage, and no business rule says who wins when an office and a cloud copy edit the same invoice.
Decision
Make the agency's SQLite database the only master. Cloud services may instruct the application — block, update, configure — but never write operational data.
Trade-off
The cloud can only report on data that was deliberately synced, and support cannot correct a record remotely.
Result
Offline operation is a property of the architecture rather than a feature that can regress.
D02
One installer, three run modes
Constraint
Offices grow from one PC to several desks on one set of books, and SQLite over a network share corrupts.
Decision
Ship one binary that runs as local, server or client. Server mode exposes the same handler implementations over HTTPS; the React interface is identical in every mode.
Trade-off
Every handler must work in all three modes — anything returning a file returns bytes, not a path — and mixed versions on one LAN need explicit rules.
Result
An agency moves from one PC to a networked office without switching products or running a data-migration tool.
D03
Authorization lives in one fail-closed table
Constraint
In server mode, network requests reach handlers directly, so checks inside the user interface protect nothing.
Decision
Classify every IPC channel as public, authenticated or admin in one table consulted at both entry points. The application refuses to start if a registered channel has no entry, and CI runs the same comparison.
Trade-off
The table controls reachability only; handlers that shape data differently per role keep their own checks.
Result
No new channel can reach an agency without an explicit authorization decision.
D04
Migrations only move forward
Constraint
A migration runs against the customer's only copy of their data the first time an installer opens — there is no staging environment.
Decision
Numbered, append-only migrations applied under one lock, additive changes preferred over table rebuilds, and a backup taken by the new version immediately before it migrates.
Trade-off
There are no down-migrations: rolling back a schema means restoring a backup.
Result
Every agency database follows the same path, and rolling back application code stays clean after additive changes.
D05
Updates install themselves — with the machine's consent
Constraint
Security fixes moved only as fast as the least attentive administrator, and an office LAN had no update path at all.
Decision
Signed release manifests that carry the mandatory flag inside the signature, a compatibility gate before any download, and an office server that relays packages its desks verify for themselves — desks first, server last.
Trade-off
A mandatory update can interrupt unsaved work. A countdown mitigates it, and the flag is reserved for schema and security releases.
Result
One download per office instead of one per desk, and version order across a LAN is enforced rather than documented as a warning.

05 · Operations

Delivery and operations

Release safety: Signed manifests and artefact hashes, staged rollout with a halt switch, differential downloads, and a schema gate that refuses any update which would leave the database ahead of the code.
Backup and restore: Backups ship with the application. Restore is admin-only, limited to the backup directory, checks archive entries for path traversal, and takes a safety copy before replacing anything.
Transport security: LAN traffic runs over HTTPS with trust-on-first-use certificate pinning. A changed server certificate is never silently re-trusted.
Audit and language: Sensitive operations are audit-logged, and every user-facing string goes through i18next in both French and English.