An owner invites a teammate to their organization. Three sentences of product, and a teammate who is not a user yet cannot be reached inside the app. ...
|
Feb 26, 2026The Giant Context console now runs as a native desktop app, in its own window, out of the browser entirely. It is not shipped and I am not sure it should be.
Giant Context is API-first. The console is a single-page app that talks to the API and holds no knowledge of its own, because the architecture put the API at the centre and made every screen a replaceable satellite of it.
Which makes the presentation layer disposable. If the way I render the console turns out to be wrong for a surface, that layer gets thrown away and rebuilt, native or otherwise, without the backend noticing.
So the cheap thing to try first is wrapping the existing web app in a native window. If it is good enough, a desktop app costs a shell. If it is not, the same decoupling that made the cheap version possible is what would let me build a real native client later, and the API is unaffected either way.
The repository has had the packages for both since its second week:
One console, four frames
packages/ core/ the console (the SPA) web/ it, in a browser tab desktop/ it, in a native macOS window mobile/ it, wrapped for iOS and AndroidOnly the browser build ships today. Desktop and mobile are the same console in different frames, and neither is a second build of the product.
I do not know if the desktop app matters.
The big AI products all shipped desktop apps recently, and there is a theory that an icon in the dock makes a tool stickier than a bookmark, that people return to what sits on their machine. Maybe. I do not have data, and I am not going to pretend a hunch about stickiness is a strategy. The desktop app was cheap to try because of the architecture, so I tried it. If it earns its place, good. If not, it cost me a shell.
When a new surface costs a shell rather than a rewrite, you can find out whether it matters instead of arguing about whether it might.
Giant Context is being built to do a business's marketing rather than to hand it faster tools. It works out what a company needs said and generates the pages, the campaigns and the posts that say it. None of it ships without approval, so everything it produces is a proposal waiting on a person.
That approval is where the product either works or does not. The platform runs around the clock, and if the yes it is waiting on lives in a browser tab on a desk, the platform becomes another dashboard nobody opens, and a marketing engine nobody checks produces nothing.
So the approval has to arrive where a person already is. A notification arrives saying next week's campaign is drafted. You are in line for coffee. You read it, tap approve, and it ships, or tap reject and it tries again. Your marketing advanced while you waited for an espresso.
Building the invitation feature meant building a whole notifications system to send one email, a provider-agnostic layer every part of the platform speaks through. At the time that was over-engineering for a feature that needed to send a link.
Email is one channel. A push to a phone is another, and the reason to make notifications a system rather than a function that sends mail is that the platform has to reach a person through whatever channel they actually watch. The invitation email and the campaign-approval push are the same system with two providers behind it, and the second one only works because the first was not hard-coded to a mail vendor.
The experiment ran on Electron, which ships a browser engine inside every app, so a console window becomes a bundle measured in hundreds of megabytes. It got the console into a native window in days, which is what a research spike is for, and it is the wrong thing to ship on a platform where I have spent months keeping payloads small. If a desktop app becomes real here it will not be Electron that ships it. There are lighter ways to wrap a web app in a native shell, and I have started reading about them.
Build the product once, behind an API, and no screen holds anything the others need. Desktop, mobile, or a surface that does not exist yet stops being a rewrite and becomes a frame. Most of them are worth trying because they are cheap. For this platform, the one that decides whether the product works at all is the phone.
Remote, Pacific time, full-time or contract. Get in touch.