Giant Context builds and hosts websites. The website is the product, public, indexed, served fast to strangers. The console is the portal where a customer builds and manages theirs, an authenticated app behind a login. Two surfaces, opposite jobs. The console is not a Next.js app, and it is not react-router or TanStack Router either. Routing there is a system we own outright, and there was never a bake-off. The reason is the closest thing this codebase has to a thesis:

The architecture committed to its structure before this repository was two weeks old. The API is the hub, and everything that renders is a satellite. The API describes itself in an OpenAPI schema, and every consumer works from that description, the browser SPA that is the console, the Electron desktop shell, a native mobile client if one ever becomes necessary, the SDKs, and consumers that aren't browsers at all. Tool-calling agents landed in the repo earlier this month. None of them get a private contract. The schema is the contract.

Satellites are replaceable on purpose. Electron is a solid way to wrap an SPA into a desktop app, and I don't fully trust it as a long-term answer, because wrapper quality is somebody else's roadmap. If the day comes when only a real native app will do, the satellite gets swapped and the hub doesn't move. That is the position I want. The presentation layer stays decoupled from the schematic nature of the API, so that no rendering choice made this winter can hold the data model hostage in year three.

The hub pays in directions that have nothing to do with rendering, too. A self-describing API gives you a Swagger surface for free, generated client bindings for free, and one place where permission checks live against the schema instead of once per rendering framework.

Next fights this shape. Next is not a router. It is a commitment to a rendering server, and the server becomes the center of gravity. Routes live in its world, data fetching threads through its lifecycle, and the presentation layer grows roots into a machine you now operate. If the architecture says clients are dumb satellites of a schema, putting a server-centered framework under the console is architecture by accident.

Next earns its keep when server rendering is the product, for pages that must index, first paint for anonymous cold visits, markup assembled before the client wakes up. That is a precise description of the websites this platform hosts, the thing customers come here to make. They exist to be found and to load fast for strangers, so they render through Next. The console is the opposite case, behind a login, nothing to show a crawler, long warm sessions where a served HTML shell buys nothing.

Three weeks ago, on December 30th, both decisions landed eight hours apart.

The objection to a homegrown router was never the runtime. Path matching is a solved problem the size of a util file. The objection is everything around it, keeping the route table, the view files, and the types in agreement, forever, by hand. That maintenance bill is what makes "just use the framework" the right default.

Here, the bill is already paid. The generated package runs ten generator scripts:

In the first line, the client's API bindings materialize from the running dev server's own OpenAPI spec. That 127.0.0.1:5175 URL is the API describing itself. The description becomes typed code. The same machinery emits the query cache keys, the data hooks, the form validation, the mocks and factories the tests run on, and the same one-declaration habit keeps the reactive layer honest. Routing is a customer of the generator, not the reason it exists.

In that context, file-based routing is a filesystem that is already a declaration.

A directory means a path. A [bracketed] directory means a parameter. A view.tsx means a page. The generator walks the tree and emits the route table, and the build refuses to proceed without it. The fix commit that pinned this down says ensure routes are regenerated before typecheck and build. The tree is load-bearing, and the compiler is its enforcement.

That import identifier is a name only a generator would write, and that is the point. Nobody will ever type it. The filesystem types it. Generated code answers to one aesthetic. Correct, regenerable, never edited by hand.

What is left for the runtime? Match the path, mount the view, hand over the params. The whole "framework" is a small Router component and its utils, code you can hold in your head, which means code you can afford to own.