Why A Desktop
Most web applications are built to move you along one path. You are on one page, looking at one record, doing one task. When you need to check something else while you work, you open another browser tab, and the connection between the two lives in your head. That is a reasonable design for a storefront. It is a poor design for the internal software a team lives in all day, where the job is usually to compare, cross-check and act on several things together.
A desktop solves this by laying the work out in space. The order you are editing, the customer it belongs to, the report that flagged it and the queue it came from can all be open at once, each in a window you can size and place where it is useful. Nothing has to be remembered, because nothing has to be closed to see something else.
The case is stronger when an assistant is doing part of the work. When an agent writes a component, the developer wants the generated code, the running result, the table it reads from and the log of what happened, all visible together. A single-page interface makes that sequential. A desktop makes it a glance.
“A single page asks you to remember what you just closed. A desktop leaves it open.”
How The Desktop Is Built
The desktop is not a theme painted over a page. It is a window manager running in the browser: it handles which window is in front, which has focus, how windows talk to each other, and where they were left. What makes it different from other windowed web interfaces is where its parts come from.
Each application runs in its own frame, with its own document and its own global scope. One application’s styles cannot restyle another, and one application’s variables cannot overwrite another’s. This is separation for correctness and maintainability. It is not the security boundary; that boundary is the tenant, and it is described on the security page.
An application’s window settings, such as its title, size and icon, are stored as a record alongside the application’s interface, backend and schema, all under the same name. Changing how a window opens is the same kind of write as changing what it does, and it is live the next time the window opens.
What appears on a tenant’s desktop and in its launch menu is read from the tenant’s own records when the desktop loads. Adding an application to the desktop does not mean editing navigation markup and shipping it. An assistant connected through MCP can place and remove shortcuts directly, inside the one tenant it is bound to. Build with MCP.
The desktop itself, including the taskbar and the window manager, is resolved from the same store as the applications that run on it. There is no separate front-end build for the shell, so the platform’s own interface follows the same rules it asks applications to follow.
When work is promoted to production, it moves through one gated path that carries code, schema, shortcuts and users together. An application does not arrive in production without the shortcut that opens it, and a shortcut does not arrive pointing at an application that is not there.
Questions Worth Asking
A windowed interface is a deliberate departure from how most web software looks, so these are the questions we would expect from someone deciding whether to put it in front of their users.
Is this a remote desktop?
No. Nothing is streamed from a server as pixels. The desktop and every window on it are ordinary web pages running in the user’s browser tab, and each window talks to the platform the same way any web application does.
Will our users have to learn something new?
Less than with most new software. Windows, a taskbar, a launch menu and desktop shortcuts are conventions people already use every working day. The unfamiliar part is finding them in a browser, not learning how they behave.
Can an application still be a single screen?
Yes. A window can be one focused screen, and many will be. The desktop does not force every application to be complicated. It means a simple application can sit next to the other things a user needs, instead of replacing them.
Is this a style choice we could turn off?
It is the interface model of the platform rather than a theme. We would rather say that plainly than suggest it is a preference you can toggle. If your users need a conventional single-page site, that is a real requirement, and it is worth raising early.