My stack, and why it’s boring on purpose

Four builds went to production this year: a brewery, a brand studio, a helicopter parts distributor, and an internal onboarding platform for a real estate brokerage. Four businesses with almost nothing in common. Under the hood, the sites are nearly the same.

framework   Next.js     every project
hosting     Vercel      every project
content     Sanity      where staff edit content (the brewery, the studio)
database    Supabase    where it's an app (the brokerage platform)
email       Resend      contact forms and transactional mail
booking     Cal.com     so "let's chat" means a booked call

Not one of those is an interesting choice, and that’s the point. Every part is mainstream, heavily documented, and used by teams a thousand times my size. When something breaks at 11pm, the answer is already written down somewhere. When a client eventually hires someone who isn’t me, that person will have seen all of it before. Boring, from the outside, is what reliability looks like.

There’s a version of this trade where the client pays for novelty twice: once while the developer learns the exciting new framework on their invoice, and again when the next developer can’t pick it up. Owner-operators feel that second payment the hardest, because they don’t have a bench. If I disappeared tomorrow, every one of these businesses could hand their repo to a competent Next.js developer — of which there are tens of thousands — and carry on.

Boring foundations are what make interesting features affordable.

The repetition is where the real compounding happens. The contact plumbing I got right for the parts company was already right when the brewery needed it. The publish-and-it’s-everywhere pattern from the brewery informed the studio’s handover. Every problem solved on one project arrives pre-solved on the next, which means less of each budget goes to plumbing and more goes to the parts a guest or a customer actually touches. The brewery’s menu has a slot machine that spins beer flights. It could afford one because nothing underneath it was experimental.

Same reason the running costs stay small. Boring parts are commodity parts, and commodity parts are cheap: the brewery’s whole stack costs less per month than the template subscription it replaced.

If you’re hiring a builder, here’s the diagnostic: ask what their last three projects ran on. If it’s the same answer three times, you’re buying a system that’s been debugged on other people’s budgets. If it’s three different answers, you’re not hiring a stack — you’re volunteering to be the test site for one.

The four builds are on the work page, same bones under every one.