Building in Public: Our Tech Stack for 2026

ByteMelt runs on nine production dependencies. Nine. A typical Next.js project with a CMS, auth layer, and database has somewhere between twenty and forty. So our attack surface is roughly four times smaller.

No database. No CMS. No auth. The entire site can be reconstructed from a single git clone. We didn't arrive here by accident. It was genuinely the first decision we made, and the one I'm most sure about.

Three Services

Next.js renders the pages. Resend sends the emails. Vercel deploys and hosts. That's it. Everything else lives in the repo.

Here's the full production dependency list: next, react, react-dom, next-mdx-remote, gray-matter, reading-time, resend, zod, and @tailwindcss/typography. You could read the entire package.json in thirty seconds and understand exactly what the site does.

Now try that with a project running Prisma, NextAuth, a headless CMS SDK, an ORM, a state management library, and a CSS-in-JS runtime. Good luck.

We're on Next.js 16 with Turbopack, which is now the default bundler (not experimental anymore). Production builds are two to five times faster. Fast Refresh is up to ten times faster during development. Server Components ship zero bytes to the client. Code that runs on the server stays on the server. And with Server Components as the default, client-side JavaScript drops by up to 70% compared to a traditional client-rendered approach. That number genuinely surprised me.

Performance budget: FCP under 2.0 seconds on mobile 4G. First load JS under 100KB. Lighthouse above 90. We self-host our fonts (Outfit for headings, Space Mono for code, DM Sans for body) so there are zero external CDN requests. No network calls just to render text. I spent way too long on the font loading strategy for what amounts to a cosmetic detail, but that's the kind of rabbit hole I enjoy.

Content as Code

All our content is MDX. Markdown with React components baked in. Files live in the repo under /content. Every article, every edit, version-controlled through Git. You can diff a post, revert it, branch it.

Josh Comeau runs his blog on MDX. Lee Robinson, formerly VP at Vercel, championed MDX-powered blog templates. Kent C. Dodds created mdx-bundler and builds his site with it. These people have access to every CMS platform on earth. They chose MDX because it's portable plain text that happens to support interactive components. No vendor lock-in. No subscription costs. No third-party dependency that goes down at 2 AM while you're asleep.

Can non-technical editors publish through a visual dashboard? No. For a two-person operation making ten to fifteen posts a month, we don't care. We write in VS Code. We commit. The site rebuilds. Done.

Design in One File

Tailwind CSS v4 moved from JavaScript configuration to pure CSS @theme declarations. ByteMelt's entire design system, eleven brand colors, three font families, all the spacing and typography, lives in a single globals.css file.

No tailwind.config.js. No design token pipeline. No build step to translate tokens from one format to another. You open one file and you see everything. If you've ever spent an afternoon debugging why a config change didn't propagate through a build chain, you already know why this matters.

What We Didn't Build (Yet)

There's a file in our repo called CLAUDE.md that lists locked architectural decisions, including what we deliberately chose not to build.

No CMS until content volume justifies it. No database until we ship community features that actually need one. No auth until there's something worth logging in for. Sanity v3, MongoDB Atlas, Auth.js are all in the Phase 2 plan. They stay there until we have a real reason to pull them forward.

I think the useful version of building in public isn't sharing revenue numbers and growth metrics. It's sharing decisions. What you chose, what you didn't, and why. That's the part that actually helps someone building their own thing.

Nine Dependencies Is a Runway

You don't get simplicity by removing things later. You get it by not adding things you don't need yet. Sounds obvious. It's incredibly hard in practice because every tool looks useful when you're setting up a project.

The site is fast because there's almost nothing to slow it down. And right now that lets us focus on the only thing that actually matters, which is making things worth reading.