Nuxt and Supabase as a Solo SaaS Stack

The usual advice is to pick the best tool for each job. Running products alone, I do the opposite: every one of them sits on the same stack — Nuxt and Supabase — and the sameness is the point. Nuxt gives me a full-stack Vue app in one codebase: server-side rendering (which matters when a product leads with content and has to rank), server API routes, and one mental model for front and back. Supabase gives me Postgres, auth, storage and row-level security as a managed backend, so I never rebuild login or babysit infrastructure. Together they let one person ship a complete SaaS. But the leverage isn't in either tool. It's that Delivery Sheet and Listemizde run on identical plumbing, so nothing is bespoke and everything I learn on one carries straight to the other.

What each does

• Nuxt — the full-stack Vue framework. One codebase covers the app, the server API routes, and server-side rendering. SSR earns its keep on products that lead with content or need to rank: the pages arrive as real HTML for search engines and AI crawlers, not an empty shell that fills in a beat later.
• Supabase — the managed backend: Postgres (a real relational database, not a toy), authentication, storage, and row-level security to keep one tenant's data out of another's. It removes the two things that quietly eat solo builders alive — hand-rolling auth, and running infrastructure.

Between them, the parts of a SaaS that used to need a backend team are simply already there.

Why this combo for solo

The constraint on a solo builder isn't ideas, and it isn't even code — it's attention. Anything you have to hold in your head that isn't the product is a tax on the part that matters. Nuxt and Supabase keep that tax low: one Vue developer owns the whole thing, auth and the database are already solved, and deployment doesn't fight you. One language, one mental model, one codebase — and the thinking goes to the problem instead of the plumbing.

The real trick: the same stack every time

"

For a solo builder, sameness is speed. The moment each product gets its own clever architecture, a portfolio turns into a maintenance burden no one person can carry. Boring and repeated is the feature.

Here's the discipline that actually makes multiple products possible: the stack never changes. What I learn debugging Delivery Sheet applies directly to Listemizde — same deployment, same patterns, same instinct for where a bug hides. I can move between them without re-learning my own architecture. A different clever stack per product would be more interesting to build and completely unsustainable to keep alive. The dull, repeated infrastructure is exactly what frees my attention for the part that's genuinely different between two products: the problem each one solves.

The SEO angle

Because my positioning is content-led — products found through writing and search rather than ad spend — Nuxt's SSR isn't a nice-to-have. Content-led products need pages that are real, crawlable HTML with proper metadata and structured data, not client-rendered shells that a crawler sees blank. Nuxt does that by default, so the same stack that runs the app also serves the discovery engine that brings people to it. One stack, both jobs.

What it's not

This isn't the optimal stack for everything, and claiming otherwise would be the kind of thing I distrust when other people say it. Heavy real-time systems, exotic data models that fight Postgres, or products needing a large specialised backend team are better served elsewhere. But a solo stack isn't chosen for per-problem optimality — it's chosen for being consistent and fast enough for the problems I actually build, so the plumbing never becomes the project.

What usually goes wrong

• A new stack per product. Chasing the interesting choice each time and drowning in bespoke architecture one person can't maintain.
• Rebuilding auth and infra. Hand-rolling the solved problems instead of taking Supabase's, and losing weeks to plumbing.
• Client-only rendering for content products. Shipping empty shells that don't rank, then wondering why search sends no one.
• Optimising the stack instead of the product. Polishing infrastructure that's already good enough while the actual problem waits.

Pick one solo-friendly stack — mine is Nuxt and Supabase — run it for every product, and let the sameness carry the speed while your attention goes to the problem. The best stack for a solo builder isn't the most powerful one; it's the one you know cold and never have to think about. That's rule four of my operating system, and it's quietly why the whole portfolio stays sustainable.

Part of Building AI Products. See also my product operating system and why most AI-built apps feel like demos. The newsletter sends one practical build lesson every two weeks.