The AI-era stack we're building on

Every studio has a stack. Ours is deliberately boring in most places and opinionated in a few. Here's what we're building on, and why.

The web side

For apzilon.com and play.apzilon.com, we use Next.js 16 with React 19 and TypeScript. Strict mode everywhere. No JavaScript in the codebase.

Styling is Tailwind CSS 4, the CSS-first version. No tailwind.config.ts — theme tokens live in globals.css via the @theme inline directive. Less indirection, fewer files, faster mental model.

We deploy to Vercel. Not because it's fashionable, but because Next.js + Vercel is a finished product. You don't spend weekends debugging build pipelines. You ship.

The game side

For games, we use PixiJS 8. We considered Phaser, Babylon, and bespoke Canvas2D — PixiJS won on three counts: WebGL performance, small bundle size, and a community that still ships things.

Each game lives in its own repository, deployed to its own Vercel project at a subdomain of apzilon.com. The portal at play.apzilon.com embeds the game via iframe. This keeps games independently versioned, independently deployed, and completely decoupled from the portal's marketing concerns.

The AI tools

Claude Code is our primary pair programmer. We're not here to argue about whether AI writes "real" code. The argument is over. The question is how to use it well.

For us, that means:

1AI writes boilerplate, typing, and repetitive patterns

2Humans decide architecture, scope, and quality gates

3Every AI-assisted commit gets the same review as any other commit

4Credit is given openly in devlog and release notes

For image generation, we use Gemini Nano Banana Pro via Google Flow. For pixel art specifically, PixelLab and Ludo.ai MCP.

What we don't use

A short list, because it matters:

- **No state management library beyond Zustand** — for game state only - **No animation library** — Tailwind + CSS keyframes cover 95 percent of what we need - **No component library like shadcn/ui** — we keep Tailwind raw to stay minimal - **No CMS** — devlog and product data live in TypeScript files in the repo - **No database** — at least not yet. Static generation beats dynamic queries for marketing sites - **No analytics SaaS with tracking** — Plausible only, privacy-friendly

Each of these will change if and when we actually need them. Not before.

Why no database?

This is the question we get most often. The answer is simple: for marketing sites, product catalogs with fewer than 100 items, and devlog posts counted in the dozens, a TypeScript file is faster, safer, and simpler than a database.

- Type-safe at compile time - Version controlled in git - Zero latency (static generation) - No backup or migration complexity - Free to host forever

When we have user accounts, leaderboards, or real-time features — we'll add a database. Probably Turso or Neon for simple SQL, or Upstash Redis for game state. Until then, files.

Updating the stack

The stack isn't sacred. It's the current best guess. We'll revisit it every quarter and when something in the wild changes — Next.js 17, Tailwind 5, a better PixiJS alternative.

The goal is not to use the newest tools. The goal is to ship the best work we can, and the stack is just the toolbox.

Next post will be about the actual work — what Soul Warden looks like under the hood.