Desktop apps that print, work offline and update themselves, with one codebase for Windows, macOS and Linux. For counter and retail operations.
Free first conversation · Reply within 1 business day
Bottle POS (Quilt Software / PosNation):
Electron 35 and React 19 for 3,000+ retailers
60versions in 11 weeks through a parallel Windows, macOS and Linux pipeline
Silent ESC/POS thermal printing, customer display and offline detection
Zero-touch updates:
Self-hosted release server, channels and staged rollouts
Bottle POS (Quilt Software / PosNation): Electron 35 and React 19 for 3,000+ retailers
60 versions in 11 weeks through a parallel Windows, macOS and Linux pipeline
Silent ESC/POS thermal printing, customer display and offline detection
Zero-touch updates: self-hosted release server, channels and staged rollouts
The web-based register stops selling when the internet goes down, and the line in the store grows.
The thermal printer only works through a browser plugin, and every browser update breaks printing.
Updating the app takes remote access machine by machine, and every store runs a different version.
The team knows web, and nobody wants to maintain three codebases for Windows, macOS and Linux.
One codebase in Electron and React produces the installers for all three systems, so one team maintains the app on every machine.
Silent ESC/POS thermal printing with no browser plugin and no dialog box, customer display, printer discovery and a print test tool.
Detection of a dropped connection, local storage and sync when the internet comes back, with the conflict rules defined in the spec.
A release server, distribution channels and staged rollouts, to update every machine with no technician visit and no action from the user.
Bridges between the desktop app and your web system or API, with role-based access control, to reuse what already works without a rewrite.
Parallel builds for all three systems, automated tests and CI gates, to ship new versions often and without surprises.
See also: mobile app development and legacy modernization.
Bottle POS: desktop app in Electron 35 and React 19 for a cloud POS in liquor retail, with zero-touch updates recorded in 5 ADRs and bridges to the legacy web POS.
Related experience, in POS: multi-tenant ERP SaaS with a POS module, multi-warehouse inventory and Brazilian e-invoicing (NF-e).
Facing a similar challenge? Tell us the problem and the timeline.
Free first conversation · Reply within 1 business day
Desktop application development is the building of software installed on Windows, macOS and Linux for jobs the browser does not handle well: printer and display integration, offline operation and all-day use at the counter. Hire it when the operation depends on local hardware, must keep running offline or needs control over updates on every machine.
We map the operation, the hardware, the existing systems and the fleet of machines. You receive the recommendation between desktop and web, the architecture, the update strategy, the plan and the estimate.
Decisions on updates, offline operation and hardware access recorded in ADRs, with acceptance criteria per flow. You approve the decisions before the code.
The biggest risk first: the packaged app talking to the real hardware and to your system. You receive test installers to validate in the store or at the office.
Remaining flows, automatic updates, the pipeline for all three systems and automated tests. You receive the installers, the release server and the operations documentation.
Staged distribution through channels, tracking of the versions in the field and new features, under a monthly retainer or handed over to your team.
| Scope | Typical timeline | Engagement model |
|---|---|---|
| DiscoveryOperation, hardware, architecture, update strategy and estimate | 1–2 weeks | Fixed-scope project |
| Proof of conceptPackaged app, integrated with the hardware and your system | 2–4 weeks | Fixed-scope project |
| ProductionFull app, automatic updates and the pipeline for all three systems | 6–12 weeks | Fixed scope or time & materials with a cap |
| Ongoing evolutionNew versions, new devices and rollout through channels | Ongoing | Monthly fractional retainer |
Timelines are typical ranges. Discovery defines the scope and the estimate of each project; the contract can be in USD or BRL.
Want to know which format fits your project?
Free first conversation · Reply within 1 business day
On the desktop, AI speeds up the build under the same rules as any of our projects and only enters the product when there is a clear use case.
In the buildAI coding agents (Claude Code, Codex, Cursor, Copilot, OpenCode) implement handlers, screens and tests from approved specs.
What humans reviewThe architecture decisions recorded in ADRs and every merge go through senior human review.
Quality gatesAutomated tests, CI gates and pre-commit hooks block regressions before each version.
AI in the appAssistants and automations call the model through an API, with guardrails and a log of every call.
Local dataWhat stays on the machine only leaves it when the spec says so, and it is never used to train models.
| Criterion | Web app | Electron desktop app | Native desktop app |
|---|---|---|---|
| When it makes sense | Use in the browser, with no local hardware | Local hardware, offline operation and a team with web experience | Graphics performance or deep integration with one operating system |
| Local hardware | Limited to the APIs the browser exposes | Printers, displays and files reached through Node.js | Full access to the operating system APIs |
| Working offline | Possible with service workers, within browser limits | Local storage and sync inside the app itself | Local storage and sync, implemented per platform |
| Updates | Immediate: publish to the server | Auto-update with channels and staged rollouts | Installers or the store of each system |
| Codebase and size | One web codebase; nothing to install | One web codebase for all three systems; bundles Chromium, so installers are larger | Usually one codebase per system; smaller binaries |
Web is the default; desktop pays off in three cases: integration with local hardware, an operation that cannot stop without internet and the need to control the version on every machine. If none applies, a web app costs less to maintain. Combining both is common: the existing web interface inside a desktop shell that handles the hardware.
Yes: with Electron, a single codebase produces installers for all three systems. On Bottle POS, the desktop app of Quilt Software / PosNation, we shipped 60 versions in 11 weeks through a parallel pipeline for Windows, macOS and Linux. Windows and macOS expect signed installers; signing goes into the pipeline with your company certificates.
Yes. On the desktop, the app talks straight to the hardware: silent ESC/POS thermal printing with no dialog box, customer display and printer discovery. On Bottle POS, communication between the interface and the system goes through 61 IPC handlers, and there is a thermal-printer test tool. Other devices are assessed in discovery, with the real equipment.
Through automatic updates, with no action from the user: the app checks a release server, downloads the new version and applies it. Channels separate stable versions from test ones, and staged rollouts release the update to part of the machines before all of them. On Bottle POS, this zero-touch strategy was recorded in 5 ADRs and uses a self-hosted Laravel 12 release server.
Yes, for what the project defines: the app detects the dropped connection, keeps operating on local data and syncs when the internet comes back. What works offline is decided in the spec, flow by flow, because operations such as card payments depend on external services. On Bottle POS, offline detection is part of the app.
Yes: an Electron shell loads the existing web system and adds what the browser cannot do, such as silent printing, device access and controlled updates. On Bottle POS, JavaScript bridges connect the desktop shell to the legacy web POS, without rewriting the platform. Discovery checks authentication, sessions and the parts of the web system that need adjusting.
Electron is the more predictable choice when the team knows web and the app must behave the same on all three systems, because it bundles its own Chromium and Node.js. Tauri uses the webview of each system and a Rust core, which yields smaller installers, with rendering differences across systems. Our production experience is with Electron.
AI-focused IT consultancy
Senior engineering from discovery to delivery: whoever designs the architecture also writes and reviews the code.
Master Timm · Updated on
In the first conversation we look at the operation, the hardware and the current system, and tell you plainly whether the case calls for a desktop app, a web app or both combined.
Free first conversation · Reply within 1 business day