Desktop boundary
The React interface talks through typed Electron IPC. Database and device operations stay inside the main process with Node integration disabled in the renderer.
Electron · React · TypeScript
← Explore work
PRODUCT / ENGINEERING EVIDENCE
AlCaisse
Retail checkout designed to work even when the internet does not.
An offline-first Windows desktop point-of-sale case study with transactional SQLite sales, stock consistency, receipts, backups and explicit hardware validation limits.
Existing product image from the portfolio. Screenshots illustrate the application, not independent proof of production use.
01 / CONTEXTThe problem
The problem
behind the interface.
A retailer cannot afford to lose a sale, corrupt inventory or depend on a remote API at the counter. AlCaisse explores the transaction and recovery rules behind an offline Windows checkout application, rather than relying on a hosted dashboard.
Cash session→Barcode→SQLite sale→Stock movement→Receipt→Close session
02 / ARCHITECTURE
Designed around constraints.
Technology choices are explained through what they protect or enable, rather than listed as logos.
Local transactions
Cash sessions, sales, stock decrements, cancellation and corrections live in SQLite. The project includes an executable critical-path smoke script.
SQLite · Local data modelHardware and recovery
Receipt printing has a test-to-file path and device adapters. Backups and guarded restore are implemented, but printer and drawer results must be verified physically.
Windows · ESC/POS · Backups03 / EVIDENCE
What can actually be checked?
No invented clients, invented numbers or imaginary certifications. Each statement has a clear verification boundary.
CLAIMAVAILABLE EVIDENCEBOUNDARY
Actual desktop source
Private Electron entry point, main database service, local backup service, printer adapters and renderer are implemented.
Private repository; source review by authorized arrangement.
Executable test scenario
On 23 October 2026, a Windows GitHub Actions runner compiled the application and executed scripts/smoke-critical.js against a temporary SQLite database: ok=true with 17 named control areas (revision 08a87ad).
Private CI run 40002483409 passed; public visitors cannot inspect its logs without access. This does not validate a packaged EXE, device peripherals or main-process IPC authorization.
Windows release pipeline
A Windows package workflow exists with native SQLite binary validation for target CPU architectures.
Earlier Windows 7 packaging attempts failed while rebuilding native SQLite dependencies. A runner compatibility fix is under test. Physical Windows 7 hardware acceptance remains unverified.
Offline-first design
Critical checkout persistence uses the local SQLite database and is designed not to require network access.
Power-loss testing, field validation and operational acceptance are still required.
04 / ENGINEERING HONESTYWhat is not
What is not
proven yet.
- A browser presentation is not a runnable Windows desktop demo and cannot validate peripherals.
- Default development PINs and legacy Windows 7 compatibility are security concerns, not production recommendations.
- No confirmed physical ESC/POS printer, cash drawer validation or fiscal certification.
- No asserted real store adoption or performance improvements without evidence.
A responsible prototype is explicit about the tests it passes and the production checks it has not passed.
EXPLORE THE ACTUAL WORK
Look beyond the mockup.
The public presentation explains the intended checkout workflow. A packaged Windows demonstration and target-hardware acceptance remain the most important next evidence items.