Design first, code later

This platform didn't start with create-next-app. It started with a question: what exactly is being built, and which decisions must not be wrong?

Three decisions that hold everything else

1. A modular monolith, not microservices. The site has two faces — a public storefront and a private workspace — on top of one thin kernel (auth, per-schema database, feature flags, queue, registry). Modules plug in and out via a manifest; what keeps it honest is lifecycle discipline: every feature is an experiment until promoted, or it gets buried.

2. Content = git + MDX. Posts here are interactive — they contain React components — so any CMS can at best manage the prose. That's why content lives in the repo: prose, components, assets, and rollback in a single pull request.

3. The kernel is built by pull, not push. Phase one (this site) needs no database, auth, or queue — so none exist yet. They arrive together with the first module that genuinely needs them.

Research before the first commit

The stack was chosen through research, not memory: Next.js 16 for one end-to-end language, Drizzle + Postgres following in phase two, pg-boss for a Redis-free queue, Better Auth for sign-in. The biggest reason isn't features but the agent era: 2026 research shows the bottleneck moving from writing code to verifying it — and one language means one verification surface.

That's also why CI gates ship from the first commit: typecheck, lint, test, build. Agents may write the code; "done" is defined by the gates, not by claims.

Then, code

After all that, writing the code became the straightest part. The foundation you're looking at — the bilingual content engine, the module registry, the monochrome theme — is the direct result of the design above, built slice by slice, each runnable on its own.

Next posts will go deeper into technical territory — with diagrams you can play with, not just look at.