Why We Built Our Own IDE Instead of Renting One

There's a reasonable version of this story where it never gets built. Cursor is a genuinely good editor. Lovable generates a working site in minutes. Claude Code handles agentic heavy lifting from a terminal. Renting a best-in-class tool for each job is the obvious, low-effort default — and for a while, that's exactly what running this fleet of brands looked like: a rotation of rented tools, each excellent at its own narrow job.

The problem showed up not in what those tools could do, but in what they'd let us change about how they did it.

The wall you hit renting instead of owning

None of the popular AI-coding tools are built to be governed. They're built to be used. That's not a criticism — it's a scope decision, and it's the right one for most of their users. But once you're operating more than one live, transacting brand out of the same tooling, "used well by a careful person" stops being enough. You start wanting things a rented tool structurally can't give you:

• An audit trail of what an AI agent actually did, not just a chat log you'd have to scroll through to reconstruct it.
• A way to say "this kind of action can run on its own, that kind needs a human to say yes first" — and have the tool actually enforce that distinction, not just a personal habit of double-checking.
• A place for secrets to live that isn't a .env file an agent might read back to you by accident.
• Playbooks — the same operational pattern, reused across brands, instead of re-explaining the same task from scratch every time in a fresh chat window.

You cannot bolt a governance layer onto somebody else's closed product. You can only build habits around it and hope they hold. Eventually the honest move is admitting the rented tool has a ceiling, and the ceiling is architectural, not a feature request away.

The specific trigger: "download it, no API key"

The build decision crystallized around a concrete ask, not an abstract principle: get a working copy of the IDE that runs locally, without wiring up a separate Anthropic API key, using the Claude subscription already active on the machine as the brain.

At the time, the honest state of things was blunt: the Creytix IDE existed only as a browser-only Next.js route, hosted on Vercel. There was no downloadable build — no Electron shell, no packaging, no updater. And the agent panel inside it talked to exactly one place: the Anthropic API, gated behind an API key. There was no path to "use the AI I'm already paying for as a subscription, without also paying per token."

That's not a small gap to close with a config flag. "Download it" and "no API key" turned out to be the same underlying project: a desktop build that runs the actual Next.js server locally and shells out to the Claude Code binary already installed on the machine — the same one that authenticates against a subscription, not a metered key.

What got built

The shape that came out of that constraint is an Electron shell wrapping the same Next.js app that runs the hosted version, pointed at itself instead of a remote server. The main process spawns the local server, opens a window against it, and flips a brain-mode flag: when the flag says "local Claude," the agent panel's session handler shells out to the local claude binary instead of calling the Anthropic API directly. Everything downstream of that — the editor, the browser preview tab, the release-lane governance, the vault — is the same code the hosted version runs. Nothing was forked to make the desktop build possible; the local-brain mode is a second path through the same session handler, not a parallel app.

The update path came right behind it, because a desktop app nobody can update is a liability, not a convenience. An auto-update flow shipped, checking a hosted feed and pulling new builds without asking the user to manually reinstall — the same expectation any desktop app sets today, applied to a tool that's a week old instead of a decade old.

What's still open, honestly

Two pieces aren't finished. Distribution needs a real hosting location for update packages and installers — right now that's still being worked out, not a solved, load-bearing piece of infrastructure. And code signing — the step that stops a fresh Mac from throwing a scary "unidentified developer" warning on first launch — hasn't shipped yet either. Both are known, scoped, and not blocking internal use; they're what stands between "works on the machines that built it" and "something you'd hand a design partner without a caveat."

That gap is worth naming plainly rather than glossing over, for the same reason the IDE itself insists on an audit trail: a tool built around "show your work, don't just claim it" should hold its own build story to the same standard.

Why this was worth the cost

Building an IDE is not a cheap decision, and it wasn't made lightly. Every week spent on the shell, the local-brain wiring, or the update pipeline is a week not spent on a brand's storefront or a client-facing feature. The case for doing it anyway comes down to one comparison: a rented tool gets better at the thing its vendor decided to make better. An owned tool gets better at the thing you actually need next — governance, an audit trail, a vault, a way to run the same playbook across nine different brands without re-explaining it each time.

Cursor and Lovable aren't wrong tools. They're just tools built to hand you code and step back. Running a real, multi-brand operation past the point of "the code exists" needed something that stayed in the loop after the code was written — and that meant owning the loop, not renting a piece of it.