I've shipped five products in the past year. A meal-planning SaaS, a digital audit product, a token-gated delivery system, a conversion tracking tool, and a full-stack brand and web studio. Each one runs on essentially the same six tools. That's not coincidence. It's what happens when you run the same stack against real billing, real auth, real email delivery, and real production errors enough times that the choices stop being questions.
This is that stack. Not a list I assembled by reading HN threads. The one that's in production, processing payments, sending email, storing user data, and getting updated by a one-person studio on a schedule that leaves time for the rest of a life.
The pattern
Every product I've built in the past year converges on the same shape. A Next.js front end deployed to Vercel. Supabase handling auth, database, and storage. Stripe for billing. Resend for transactional email. Claude Code as the development environment. The specifics vary - different database schemas, different Stripe product configurations, different component architecture - but the layer topology is identical.
When you ship enough things alone, you stop picking tools by reputation. You pick them by how much context you have to hold in your head to keep them running. Six tools is about the limit before the cognitive overhead starts compressing the time you actually spend building.
pattern-overlay / three products, one stack
Meal-planning SaaS
Digital audit product
Token-gated delivery
same six tools, every time
Why the indie maker tech stack question matters now
Claude Code changed the marginal cost of building. A solo operator in 2025 can hold the complexity of what a four-person team held in 2022. But the tooling question doesn't go away when you add an AI collaborator. It gets sharper. You still pick the infrastructure. You still own the architecture decisions. The AI helps you execute them faster, but you're the one who has to live with a bad choice at 11pm when something breaks.
Wrong infrastructure compounds. An auth service that requires a specialist to debug, a payment processor with a confusing webhook model, an email provider that goes into spam on transactional sends - these are not one-time costs. They are recurring taxes on every hour you spend building.
The stack I use is chosen specifically to minimize those taxes for a solo operator.
Next.js and Vercel as the foundation
Next.js App Router, not Pages Router. The distinction matters because App Router lets you write server components, server actions, and route handlers in the same codebase without context-switching between a frontend framework and a separate API layer. For a solo developer, that's hours per week of saved friction.
Vercel as the deploy target gives you preview URLs for every pull request, which is useful even when you're the only reviewer. It also handles edge config, ISR, and environment variables without requiring you to manage Nginx, SSL certificates, or a deployment pipeline. The time cost to deploy a new feature is close to zero after the first setup.
Instance one: a digital product with token-gated delivery pages. The locked-page pattern - Stripe checkout triggers a webhook, webhook writes a signed token to Supabase, the token gates a Next.js route - took about a day to build end to end. It works correctly on the first customer purchase and doesn't require any manual intervention to deliver. That's the bar the stack has to clear.
Supabase as the data and auth layer
Postgres plus authentication plus file storage, managed together, with a dashboard you can actually use without a DBA. That's Supabase's value proposition for a solo operator.
The specific feature that matters most is row-level security. RLS lets you enforce data access rules at the database layer rather than writing middleware checks in every API route. For multi-tenant products - and almost every SaaS is multi-tenant - that means you can ship without a dedicated auth architecture session before each launch. You write the policies once, test them, and they hold.
The free tier is genuinely useful for products that are still finding their audience. The upgrade path to paid is a form change. There are no migration crises when you grow past the free limits.
I've used Supabase across products spanning authentication-only flows, complex relational schemas with multiple tables and foreign keys, and binary file storage for generated PDFs. The mental model stays consistent across all of them.
Stripe for payments - configure once and stop thinking about it
Stripe Checkout plus webhooks handles 95% of solo product billing scenarios. One-time purchases, monthly subscriptions, annual subscriptions, upgrade and downgrade flows, refunds - all of it works through the same pattern. You create a Checkout session, the customer completes payment, Stripe fires a webhook, you handle the event and update your database.
Instance two: a meal-planning SaaS with monthly and annual billing, plus upgrade and downgrade paths between plans. The full billing lifecycle - new subscription, plan change, cancellation, failed payment retry - runs through about 200 lines of webhook handler code. It took one afternoon to build correctly. Resend handles the post-purchase and lifecycle emails.
That's the pairing that matters: Stripe fires the event, your webhook handler processes it, Resend sends the email. Once you've built that loop once, you copy it to the next product with modifications. The cognitive overhead drops toward zero.
Claude Code as the sixth tool in the stack
Not "AI-assisted coding" - Claude Code running as an orchestrating agent in a terminal, coordinating file writes across a multi-file codebase. The distinction is practical. In AI-assisted coding, you describe what you want and accept a suggestion. With Claude Code as the workflow, you describe the full scope of a task, and the agent reads the relevant files, writes changes across multiple files coherently, and tells you what it did and why.
It changes how much complexity a single person can hold. Not by making you smarter, but by keeping more of the context active in the loop while you're working.
Instance three: I shipped a 13-file audit product in a focused build session. The product had four distinct modules, each with its own schema, API route, and front-end component. Claude Code coordinated the file writes so the schema migrations, route handlers, and components stayed coherent with each other as the work progressed. Without that, building something with that surface area solo in a single session would have required keeping the cross-file dependencies in my head the whole time, which is where errors creep in.
What the pattern tells us about solo operator leverage
The stack is chosen because each tool is deep enough to grow with you and operationally thin enough that you don't need a specialist to keep it running. That's a different criterion than "most popular" or "most powerful."
The combinatorial leverage is real. Supabase's Postgres, Stripe's webhooks, and Resend's transactional email together let you automate the full user lifecycle - signup, payment, plan change, receipt, cancellation notice - in roughly 300 lines of code. A solo operator running this stack at launch has roughly the same user lifecycle automation as a team that built it manually over a quarter.
What you give up: flexibility at the edges. If your billing model is unusual enough that Stripe's Checkout doesn't handle it, you'll write more custom code. If your database needs are genuinely graph-shaped rather than relational, Postgres will feel like the wrong tool. If your email volume is in the millions, Resend's pricing changes the calculation.
For most indie products in the $0 to $500K ARR range, those tradeoffs don't come up. The stack earns its place by staying out of the way.
“Boring infrastructure is the goal. The interesting part is what you build on top of it.”
If you want to see how this stack gets configured for a DTC or SaaS product in practice, the Operators Stack product packages the setup patterns I use across each layer. The work section has case studies from production deployments where this exact stack handled real scale.
FAQ
What is a good indie maker tech stack in 2025?
The stack that ships and stays running without requiring a team to maintain it. For most solo projects in 2025, that means Next.js with Vercel, Supabase for database and auth, Stripe for payments, and Resend for email. Claude Code as a development workflow, not just a code suggestion tool, extends how much a single person can build and maintain coherently.
Is Supabase good enough for production?
Yes, for the overwhelming majority of solo and small-team products. Supabase runs Postgres, which is genuinely production-grade. The managed layer adds connection pooling, automatic backups, and a reasonable dashboard. The main limitation is that you're on shared infrastructure at the free and lower paid tiers, which means burst performance is unpredictable. For products with spiky traffic, the Pro tier with dedicated resources resolves this.
Can I replace Vercel with something cheaper?
For most indie products, Vercel's cost is not the constraint - your time is. Vercel's preview deployments and zero-config Next.js integration save hours per month in DevOps overhead. If you're at a revenue level where Vercel's pricing is a real line item, you have the revenue to justify keeping it. The alternatives (Railway, Fly, self-hosted) require more configuration and more maintenance time.
Why Resend over SendGrid or Postmark for transactional email?
Resend's developer experience is cleaner than SendGrid's, and its pricing is more predictable than Postmark's for lower volumes. The React Email integration means you write email templates in JSX, which is coherent with the rest of the Next.js stack. It's also the newest of the three, which means the API design benefits from lessons the others learned the hard way.
Does Claude Code work for solo developers without a technical background?
Claude Code is more productive the more clearly you can describe what you want. That's not a function of technical background exactly - it's a function of being able to think through what a system should do before asking for it to be built. A non-technical founder can use Claude Code to prototype, but the output quality correlates strongly with how well the scope is defined going in.
When should a solo operator choose a different stack?
When your core product problem is the thing that makes the standard choices wrong. A real-time multiplayer game shouldn't be built on Postgres and Next.js App Router. A data-intensive analytics platform probably needs a column store. A hardware-connected product has different constraints. The stack above is optimized for the most common indie product shape: a web app where users authenticate, pay, get something, and come back. If your shape is fundamentally different, the stack question is different.
Sources and specifics
- All five products described run in production as of Q1-Q2 2026, not as demos or side projects.
- The 13-file audit product was built in a single focused session using Claude Code as the primary development workflow.
- The meal-planning SaaS billing implementation referenced uses Stripe Checkout webhooks wired to Supabase - approximately 200 lines of webhook handler code for full subscription lifecycle management.
- Next.js App Router used throughout; all examples assume Next.js 16 with React 19.
- Claude Code version in use at time of writing: current Sonnet-class model via the CLI tool.