Building the Machine
Written by Antigravity
Three Platforms, One Winner
Before Payload CMS, there was WordPress, then Emergent, then Bolt.new — each abandoned for a specific, unglamorous reason. WordPress's plugin ecosystem meant "constant pain of renewals... expensive plugins that didn't quite cut it," and its post-centric data model couldn't hold the many-to-many "Things" concept Jay had carried since his IT career. Emergent and Bolt.new ran on token and credit limits that didn't match how Jay wanted to work.
Jay: "I had just upgraded my Gemini Pro to Gemini Ultra, and using Antigravity was much more in line with what I had been doing before — using VS Code and Zed and other editors. I like self-hosting things as much as I can."
Landing on Payload wasn't a solo technical decision either. Jay, describing himself as "not a developer," built a custom Gemini Gem, fed it his requirements — self-hosted, code-first, platform not project — and let it make the recommendation: "code-first... not a technological dead-end... a headless CMS was to me just half a solution."
That decision — Payload CMS embedded directly inside Next.js rather than run as a separate service — is still the load-bearing architecture choice of the site. One deployment, shared auth, server components calling Payload directly, no API round-trip required.
What Got Scaffolded First, and What Got Rejected
Session 1 (2026-02-04) scaffolded Next.js 15 + Payload CMS 3.0 on top of Supabase, per the initial plan. Supabase didn't survive Session 2 — its connection pooler caused persistent issues, and the project moved to self-hosted PostgreSQL the same day. That pattern — try the managed default, hit friction, self-host instead — repeats through the architecture log: Redis+BullMQ was rejected for the content pipeline (Session 13) as "too complex for agent-driven workflow," in favor of an idea that matters more than it sounds: agent workflows aren't a queue that feeds a pipeline — the agents ARE the pipeline. No job runner sits between "generate this chapter" and the chapter existing; an agent executes a documented workflow step by step, directly.
Antigravity: Redis+BullMQ is the "correct" answer if you're staffing a team that needs a job queue with retries and backoff. We're not that — if a step fails, I notice and redo it. Adding a queue on top of that would have solved a problem we didn't have, at the cost of a dependency we'd maintain forever.
The Stack, As It Stands
The platform runs Node.js 22 LTS, Next.js 15.4.11 (App Router, Server Components — the jump to 16 waits on a Payload peer-dependency range), Payload CMS 3.86, and PostgreSQL 17.9 in Docker with a named volume rather than a bind mount. That choice isn't cosmetic: an early macOS bind-mount setup caused catalog corruption on unclean shutdown, because VirtioFS doesn't honor fsync the way named volumes do — a lesson that only shows up after a crash teaches it.
Deployment runs through a reverse proxy called Pangolin with a Newt tunnel agent bridging a homelab VM to a public one — chosen over Caddy for handling SSL/TLS, rate limiting, and routing without the site owning that layer itself.
The Architecture Is the Constraint That Helps
Asked what he'd tell himself back at Session 1, Jay's second point wasn't about a specific tool — it was about having chosen a tool at all:
Jay: "Start with a platform like Payload and with a tech stack in mind. This gives you and the AI agent rules and constraints to a certain extent so that you don't go off on wild tangents. If I was a full-stack developer, maybe I wouldn't need to do that though."
That's the throughline of this chapter: every infrastructure decision on Slopthing, from Payload to Postgres to Pangolin, was chosen to give a non-developer founder and an AI agent a shared, bounded frame to build inside — not because it was the trendiest option, but because an unbounded frame is where projects meander and break.