Plate III · Built

CManager

Regulator-grade. Encrypted end to end. Tamper-evident.

An offline-first, fully-encrypted case-management desktop app for UK law firms, engineered to Solicitors Regulation Authority standard.

Electron · React · SQLCipher (AES-256)

56 tables · v13
Schema
34 / 34
Schema tests
30 / 30
Security backtests
AES-256
Encryption
Overview

Personal-injury and RTA firms handle some of the most sensitive data there is, under some of the strictest duties there are. Encryption at rest, tamper-evident records and enforceable data-subject rights aren't features here — they're the price of admission.

CManager is a desktop application built to that bar: a 56-table domain (schema v13) wrapped in whole-database encryption, multi-factor auth, a tamper-evident audit trail, and the money-handling and GDPR machinery a UK firm actually needs. It passed its schema and security backtests before release.

The system in motion

Animated architecture breakdown — nodes and data paths resolve in sequence.

Full architecture blueprint
CManager detailed architecture blueprint
Data at rest — the key lives in the OS keystore, the whole database is SQLCipher-encrypted, and every write appends to a hash-chained audit log. · open full-size ↗
The stack — and what each part does
ElectronCross-platform desktop shell — runs fully offline
ReactApplication UI
SQLCipher (AES-256)Whole-database encryption at rest
OS keystoreHolds the encryption key — never on disk, never in the app
TOTP (RFC 6238)Multi-factor auth, implemented without a heavy dependency
electron-builder (NSIS)SHA-256-signed Windows installer
Under the hood

Encryption & key management

The entire database is encrypted with SQLCipher (AES-256) — not select columns, the whole file. The key lives in the operating system's keystore and is never written to disk or embedded in the application. This matters: the most common way encryption fails isn't a broken cipher, it's key management, and hand-rolled or field-by-field encryption is exactly where those mistakes live.

The tamper-evident audit log

Regulatory trust demands that history can't be quietly rewritten. Every audit entry includes a hash of the previous entry, forming a hash chain: you cannot alter or delete a record without breaking every link that follows it. The log doesn't just record what happened — it makes tampering detectable.

GDPR & data-subject rights

The app implements DSAR redaction against GDPR Articles 15, 17 and 20 — access, erasure and portability — so a firm can actually honour a data-subject request rather than promising to.

Money & reconciliation

It handles the parts a legal practice lives on: PDF invoice and letter generation, a client/office money split, and bank reconciliation — the accounting boundaries the SRA cares about, built in rather than bolted on.

Packaging & integrity

Distribution is via an electron-builder NSIS installer, SHA-256 signed, with encrypted backups — so the thing users install is as verifiable as the data it protects.

Decisions worth defending
Why SQLCipher over app-level encryption?
SQLCipher encrypts the whole database and gets key management right — key in the OS keystore, not in code. Hand-rolling encryption or encrypting field-by-field is precisely where the mistakes live.
Why a hash-chain audit log?
Regulatory trust needs tamper-evidence: each entry includes a hash of the previous one, so you can't alter or delete history without breaking the chain and making it obvious.
Why offline-first for a legal tool?
Firms want their client data on their machine, under their control, not sitting in someone else's cloud. Offline-first with local encryption keeps the trust boundary where the firm can see it.

Proof. 34/34 schema tests and 30/30 auth / IDOR security backtests passing before release.