The stack came before the product
In December I finished two years at my previous company. The next day I started a repository with no product in it, just code rules, shell tooling, testing standards, and an architecture document. Giant Context, the website platform this blog documents, got its first commit the same day that repository did, and that first commit is the template being applied. The company is three and a half weeks old as I write this.
Those years were good ones. I spent them building their platform on Azure, and the product that came out of it was a good product. But the ideas that shaped it were often other people's good ideas, the conditions were strict, and the way we built was not always the way I would have chosen. I wasn't the boss. That is the ordinary deal of employment, and I took it willingly for two years.
The day the deal ended, it inverted. Every convention was suddenly mine to set, and the first thing I did with that authority was write down the way rather than a product.
The gameplan
The template repository is small, just lint and format and test scripts, git hooks, a documentation tree, and configuration for the AI tooling I build with. Its architecture document opens like this:
Architecture Gameplan
# Architecture Gameplan
## Overview
Polyrepo architecture with OpenAPI-driven type safety betweendecoupled frontend and backend. A single ApiClient handlesauthentication, errors, and headers. Schema metadata flows frombackend to frontend, enabling auto-generated forms with zeromanual field wiring.The API describes itself. The clients are generated from the description. The forms wire themselves from schema metadata. There is no product in the repository, but the entire shape of one is pre-announced. An API at the center, a typed database under it, forms that take their validation from the schema instead of an opinion. Everything I have built in the three weeks since is that paragraph executing.
Two years on Azure
Building ManaJing's platform inside someone else's rules.
The Architecture Gameplan
The way, written down as a document before any product.
Template repo
The rules, tooling, and docs. First commit.
Platform init commit
The same day. The product adopts the way before it exists.
Schema-driven
Routes, forms, hooks, the reactive layer, all downstream.
Rules before code
The template's larger half is rules, and the reason is not taste. The plan was always that AI tooling would do most of the lifting in the codebase to come, and a generator with no conventions to obey doesn't produce a codebase. It produces output. If the rules aren't set, don't bother vibecoding.
So the rules are written the way you'd write them for a machine, which is to say specific, enumerable, and free of judgment calls. The naming section of the template's CLAUDE.md, verbatim:
| Element | Convention | Max Words |
|---|---|---|
| Components | PascalCase | 2-3 |
| Constants | camelCase | 2-3 |
| Functions | camelCase | 2-3 |
| Types | PascalCase + "Type" | 2-3 |
| Variables | camelCase | 2-3 |
A word budget for identifiers. The file anatomy sits alongside it. Every file opens with the same format header. Imports arrive spaced by category in a fixed order. Every component is a barrel with its exports in index, its presentation in view, and every function in utils. None live in the view file, which has its own mandated internal order (context, state, refs, effects, memo, render). Six non-negotiables sit above all of it, and the second one, never do backwards compatibility, has already eaten two package renames and a routing rewrite without leaving a shim behind.
Behind the CLAUDE.md sits a documentation tree with a domain for every kind of opinion. The code style doc sets prettier configuration, import spacing, export rules, comment rules, and directory structure. The testing doc sets file structure, mock patterns, type-safe mock factories, and global test providers. Error handling gets scoped error boundaries on the React side and a centralized handler with an error class hierarchy on the API side. Git hooks run as tiered quality gates. Shell scripts get a required set and a shared template with every flag explained. Architecture holds the gameplan, the biggest document in the repository. An eighth domain, global state, sat empty, a placeholder for an opinion I hadn't formed yet. Dozens and dozens of rules, and none of them describe a product, because there wasn't one.
This much specificity pays because good rules self-reinforce. AI tooling writes code by reading code. When every existing file matches the rules, every generated file matches them too. The codebase teaches its own style to whatever writes the next file, and consistency compounds. When the rules are loose, the same mechanism runs in reverse. The tooling amplifies every inconsistency it finds, and you get spaghetti at machine speed. A rule that lives in prose gets argued with. A rule that lives in the config gets obeyed, and then it gets copied.
A rule that lives in prose gets argued with. A rule that lives in the config gets obeyed, and then it gets copied.
A stack needs a test
A stack with no product is a theory. I needed something to build with it, something with real forms, real auth, real file handling, real rendering. The first idea was Elementor in React.
Elementor is WordPress's drag-and-drop page builder, and the reasoning was mostly a list of refusals. I never want to touch PHP again, or WordPress. At my previous company I rolled out PayloadCMS and it was tight (it tied into the other systems with little issue), but making Payload feel like a finished CMS takes a coder's touch, which is the same tax WordPress and Elementor charge in their own currency. The React-world builders weren't mature enough for real drag-and-drop logic. And past the builder itself there was a hosting argument. A single, cheap, distributed website (no hosting to manage, no SSL, no uptime duty, no metal) is an easier thing to want than a WordPress install, especially for the generation of developers who came up on Node and Postgres and will not touch PHP or a cPanel.
So the test case became a block-based site builder that needs no coder, on a stack coders respect, hosting included. Three weeks in, the repository holds one, with a block editor, public rendering, and multi-tenant routing. And the test case is already growing opinions. The planning document that landed just over a week ago (2025-12-28 · 186c9d918) covers embeddings, retrieval, and agent integration, a website platform that understands its own content. I think this is pointed at marketing that increasingly runs itself. We'll see what the test case becomes.
Two commits, one day
The template repository's first commit landed on December 12th (f50d0e0). Giant Context's first commit landed the same day, and its note is an inventory of everything this article has described, arriving in the product repo before any product did:
2025-12-12 · 52476a496
feat(init): initial claude code configuration
- Add CLAUDE.md with project standards and conventions- Add slash commands for analysis, debugging, development, git, workflows- Add documentation for architecture, error handling, testing, code style- Add tooling configs (ESLint, Prettier, Husky, commitlint)The platform's first recorded act was adopting the way it would be built. Nobody plans a company in a morning. What happened is simpler. The template was ready because it had been forming for two years on somebody else's clock, and the product was the first thing standing close enough to test it on.
What held, what flexed
The specifics have already shifted. The plan said polyrepo and got monorepo, said TypeBox and got schemas in the routes. The core never moved. The API describes itself. Every client, form, and hook is generated from that description, not written by hand.
That is the point of writing the rules first. The machine writes most of the code now, copying whatever is already there. I set the way down before I knew the what. Three weeks in, the what is a website platform already growing past a page builder. Where it goes from here is the rest of this blog.
Have questions?
If you're interested in my work or Giant Context, contact me!