Why we built a desktop app in the browser era
Every app became a tab. We shipped a download instead: your files, your GPU, and a plane at 30,000 feet explain why.
Count the icons in your dock that are secretly websites. The chat app, the design tool, the notes app, the project board: rendered in a browser engine, living on someone else’s servers, one tab among forty. The browser won the last fifteen years of software distribution, and it won on merit. So when we started building CSuite, an app for running AI models, the obvious move was to ship a web app like everyone else.
We shipped a desktop app instead. Not out of nostalgia, and not because we think the web is bad at software. We did it because AI work is the rare category the browser genuinely cannot contain: it needs your files, your GPU, and your machine’s time in ways a tab is specifically designed to prevent. This essay is the full argument, including the part where we itemize what the choice cost us.
Every app became a tab, for good reasons
Start by steelmanning the other side, because the web’s advantages are real and we feel their absence every week. A web app has no install step: the URL is the app. It updates instantly, for everyone, the moment you deploy; there is no version 0.4.1 population lingering in the wild. It runs identically on a MacBook, a ThinkPad, and a Chromebook from one codebase. And it is sandboxed so aggressively that clicking a link from a stranger is a safe act, which is most of why the modern internet functions at all.
That sandbox is the key word. Every browser limitation in this essay is a deliberate safety feature, built so that arbitrary code from anywhere can run on your machine without hurting you. The browser treats every page as hostile until proven otherwise, and it is right to. Our claim is narrower than “the web is over,” a case we already argued from the industry side in Why AI is moving back to the desktop: the same walls that make a tab safe for reading make it the wrong container for software whose whole job is deep access to your own computer.
Notice that cloud AI never had this problem. When the model is a frontier system living in a datacenter, the client’s only jobs are a text box and a stream of tokens, and a browser tab is the perfect thin client for that. ChatGPT-in-a-tab is good architecture. But the premise of our product is that the model increasingly runs on your machine, against your files, and the moment the model moves, the client stops being thin. It needs the disk, the GPU, and the right to keep working when the window closes. That is the moment the tab stops fitting, and it is exactly the moment the AI industry hit over the last two years.
A tab can’t hold your project folder
AI work produces artifacts: drafts, generated images, audio takes, transcripts, revisions. The natural home for artifacts is a folder you own. Watch what happens when a web app tries to give you one.
The web’s tool for this is the File System Access API, the thing that lets a page open a real directory on your disk. As of mid-2026, MDN lists its directory picker as limited availability: Chromium browsers ship it, Firefox and Safari do not, and Mozilla has formally flagged the local-disk pickers as harmful to user safety. Build your AI workspace on it and you have excluded two of the three browser engines before writing a feature. Even where it works, access is a permission the page must hold, not a property of the software you installed.
The fallback is browser storage, and browser storage comes with an eviction policy. Since 2020, WebKit’s tracking prevention deletes all of a site’s script-writable storage (IndexedDB, LocalStorage, service worker caches) after seven days of Safari use in which you don’t visit that site. Read that again from the perspective of someone storing work in a web app: take a two-week vacation and the browser may garbage-collect your projects. It’s a defensible anti-tracking rule. It is an absurd contract for anything you’d call your work.
A desktop app signs the opposite contract. In CSuite, a project is a directory of plain files on your disk. You can grep it, back it up with Time Machine, sync it with Dropbox, or put it under git. Nothing expires when you neglect it, and if you delete the app tomorrow, every file stays exactly where it was. Your work should outlive your tools. That property is table stakes in every serious creative category, a point we made at length in Serious software is local, and no browser can currently offer it.
Files buy you something subtler than safety: they buy you other people’s software. The image a model generated five minutes ago can open in Photoshop, because it’s a JPEG in a folder, not a blob behind an API. The transcript drops into your editor; the drafts folder syncs to the NAS your backup script already watches. Twenty years of tooling works on your AI output on day one, with no integration written by anyone. A web app can only offer you an export button, and an export button is an admission that your work was somewhere else all along.
Your GPU is behind glass
The second wall is compute. A useful local model is a real object: the 8B version of Llama 3.1 is a 4.9 GB download, and the models worth running for serious work climb from there into the tens of gigabytes. Running one well means loading those weights once and feeding them to the GPU at full speed, all day.
The browser’s answer is WebGPU plus WebAssembly, and honest credit first: it has come astonishingly far. The WebLLM project runs real models in a tab and reports retaining up to 80% of native performance. But look at each number in that sentence. Eighty percent is the ceiling, not the floor, and you paid for the whole GPU. Safari only shipped WebGPU in September 2025, a decade into the local-AI era. Classic WebAssembly caps a module’s memory at 4 GB, less than one mid-size model; the Memory64 extension lifts the cap but, as Mozilla’s own engine team explains, costs anywhere from 10% to a 2× slowdown because every memory access now needs bounds checks, and the JavaScript API still caps memory at 16 GB. And those multi-gigabyte weights live in the same evictable, per-site storage as everything else: two AI web apps means two separate 5 GB copies, either of which the browser may silently throw away.
Do the arithmetic against real hardware and the gap stops being theoretical. A 64 GB MacBook can hand a native runtime roughly 48 GB of unified memory for model weights and context, enough for a quantized 70B-class model. The best case a tab can offer that same machine is a 16 GB ceiling with a bounds-checking tax on every access. The browser doesn’t just slow the hardware down; it caps how much of the machine you bought is allowed to exist.
A desktop app skips the whole negotiation. CSuite talks to Ollama and to an embedded inference runtime that use Metal on a Mac and CUDA on a PC directly, with weights stored once on disk and shared across every use. The reason this matters now, and didn’t in 2023, is that the models worth running locally got good: small models are the real story of 2026, and a plain laptop runs them, but only if the software in front of them isn’t giving back performance to a sandbox designed for rendering documents.
Offline and overnight are features, not edge cases
A browser tab lives at the mercy of two clocks: the network and the tab lifecycle. Lose the connection and a cloud-backed web app becomes a login screen. Background a tab and the browser throttles it; under memory pressure, it may discard the tab outright. Again, reasonable policy for pages. Fatal for work.
AI workloads are exactly the workloads that collide with those clocks. A batch of image generations, a model download resuming across a laptop sleep, an overnight queue of transcription jobs: all of it wants a long-lived process that keeps its state on disk and keeps going when no window is focused. And the offline case is not exotic. It’s a flight, a train, a hospital wing, a client site with guest Wi-Fi. With the weights on your disk and a native runtime, airplane mode changes nothing: the model answers at altitude exactly as it does at your desk.
Could a carefully built PWA cache a small model and demo offline inference? Yes, in the right Chromium browser, until eviction. That is the difference between a tech demo and a dependency. You can demo offline AI in a tab. You can’t bet a workflow on it.
What you get in exchange: files you own
Sum the walls and the trade becomes concrete. Because the app is native, your projects are ordinary folders, your generations land on your disk in open formats, and your database is a local file rather than a row in someone’s multi-tenant cluster. Because the models run on your hardware, the marginal prompt is free, works offline, and sends nothing anywhere. Because your API keys for cloud models live in the app on your machine, they are never pooled behind someone else’s proxy.
The privacy consequence is structural, not a policy promise. A lawyer drafting around privileged facts, a doctor summarizing notes, a founder thinking through a term sheet: run against a local model, none of that content transits a server, so there is no retention policy to read, no training opt-out to hunt for, no breach to be part of. Nobody can leak what they never received. A web app can promise similar discipline in its terms of service. An offline desktop app enforces it with physics.
There’s a quieter benefit, too: longevity. A web app exists only while its company does; a desktop app with local data keeps working on your machine regardless of what happens to ours. We think about that asymmetry a lot, because in this industry, products die young and take their users’ workflows with them. If the worst happens, the correct amount of your work held hostage is zero.
The bill for going native, itemized
Now the part vendors usually skip. Choosing the desktop means paying costs the web made everyone forget, and they are not small. To ship a Mac app outside the App Store without scaring users, you join the Apple Developer Program ($99 a year, with a DUNS number required for organization enrollment), sign with a Developer ID certificate, and submit every release to Apple’s notarization scan. On Windows, unsigned installers trip SmartScreen, so we sign through Azure Trusted Signing at $9.99 a month, which itself required an identity validation that can take up to 20 business days, and SmartScreen still warns early users until the certificate accrues reputation. Every release is five installers across three operating systems and two CPU architectures. The auto-updater we had to build bakes its update-feed URL into every shipped installer, which means that URL can never move again. Our macOS build runners cost roughly ten times the Linux ones.
And yes: like most cross-platform desktop software, our app ships a browser engine inside it, which is its own small irony. The difference is where it points. This one is an engine we control, aimed at your disk and your GPU, with the sandbox walls opened exactly where the work requires; it is not a rented tab in a browser we don’t. We paid the table above because that difference is the product.
Where the web still wins, and how to decide
None of this generalizes to “build desktop apps.” If your software is collaboration on shared cloud data, ship a web app. If it’s something people touch once a month, ship a web app; nobody should install your expense tool. Our own marketing site, docs, and license console are web apps, built happily with the grain of the browser. The web remains the best software distribution mechanism ever created.
The decision comes down to three questions. Where should the files live? Where does the compute run? What should happen on a plane? When the answers are “in the cloud, in the cloud, wait for Wi-Fi,” the browser is the right container and fighting it is vanity. For AI work on your own files with your own hardware, the answers are the folder, the GPU, and keep working. Every one of those answers is something a tab is built, correctly, to refuse. So we built the other thing, paid the bill, and would sign for it again.
