DEV Community: Justin W Boggs

Claude Code's Most Underused Features

Justin W Boggs — Tue, 21 Jul 2026 20:45:50 +0000

Photo by Chris Ried on Unsplash

The most underused Claude Code features for non-tech founders are plan mode, the CLAUDE.md memory system, checkpoints with /rewind, hooks, custom slash commands, subagents, auto memory, and context management with /context and /compact. Most of us learn to type a prompt, hit enter, and hope. That works, but it leaves the majority of the tool on the table. I used Claude Code for months before I found half of these, and each one fixed a specific frustration I'd assumed was just the cost of AI coding. This post walks through all eight — what each feature does, when to reach for it, and the mistakes I made before I knew it existed.

TL;DR

Plan mode makes Claude read and propose before it touches files — the single biggest reliability upgrade for non-devs.

A CLAUDE.md under 200 lines stops you from re-explaining your project every session.

Checkpoints (/rewind or double-Esc) undo Claude's edits without you needing to understand git.

Hooks enforce rules with code; CLAUDE.md only suggests them.

Start with plan mode and CLAUDE.md this week. Add the rest as specific pain shows up.

Why does plan mode matter so much for non-developers?

Plan mode is a session state where Claude can read your code, search it, and reason about it — but it's not allowed to write to disk or run commands that change anything. You toggle it with Shift+Tab. Claude explores, then presents a plan. You approve it before anything happens.

If you only adopt one thing from this post, make it this one. Here's why it matters more for non-tech founders than for engineers: an engineer can read a diff and catch a bad change after the fact. Most of us can't, or at least can't reliably. Plan mode moves the checkpoint to before the change, where the conversation is in plain English. "I'll modify the webhook handler to verify signatures before processing, then add a test" is something I can evaluate. Four hundred lines of changed TypeScript is not.

My old workflow was: type a request, watch files change, get a bad feeling, ask "wait, why did you change that?" — after the fact, with the damage already on disk. In plan mode, the "wait, why?" conversation happens first. I push back on the plan, Claude revises it, and only then do we execute.

The habit I'd suggest: default to plan mode for anything touching payments, auth, or your database. Those are the areas where a confident wrong change costs you real money or real user trust. For cosmetic changes — copy edits, styling — normal mode is fine. I wrote more about this judgment call in when to trust your AI assistant, but the short version is that plan mode is how you buy verification time you don't have the skills to get from reading diffs.

Plan mode also changes the quality of the work itself. When Claude is forced to survey the codebase before acting, it finds the existing helper function instead of writing a duplicate. It notices the pattern your codebase already uses. Acting first and discovering context later is how you get the drift that makes AI-built codebases messy.

What is CLAUDE.md and why should you set it up first?

A CLAUDE.md file is a markdown file of persistent instructions that Claude Code reads automatically at the start of every session. It's the fix for the most annoying thing about AI coding as a non-dev: every new session starts from zero, and you find yourself re-explaining your project — where things live, what commands to run, what not to touch — over and over.

Per the official memory documentation, the guidance is to keep it under 200 lines, because longer files consume context and Claude's adherence degrades. The docs also give a rule for what belongs in it that I've found dead-on in practice: add an instruction when Claude makes the same mistake a second time, or when you catch yourself typing the same correction you typed last session.

Mine includes things like: which folders are off-limits (the boilerplate's /platform/ region), what command creates a new route, and the rule that all email goes through one central helper. Every one of those lines exists because Claude got it wrong once and I never wanted to explain it again.

Three related features most people miss:

/init writes your first draft. Run it in your project and Claude analyzes the codebase and generates a starting CLAUDE.md with build commands and conventions it discovers. You refine from there instead of staring at a blank file.

/memory shows you what's actually loaded. It lists every instruction file in your current session. When Claude ignores a rule, this is the first debugging step — half the time the file isn't where you think it is, so Claude never saw it.

.claude/rules/ scopes instructions to file paths. Rules files with a paths frontmatter field only load when Claude works on matching files. Your database conventions load when it touches schema files and stay out of the way otherwise. That's how you keep the main file under 200 lines as your project grows.

If you're brand new to the tool, my Claude Code guide for non-developers covers the setup basics; CLAUDE.md is the first thing I'd add after install.

Auto memory: the notes Claude writes for itself

CLAUDE.md is memory you write. Auto memory is memory Claude writes — and most users don't know it's happening. As it works, Claude saves notes about your project into a memory directory on your machine: build commands it figured out, debugging insights, preferences you expressed mid-session. Those notes load at the start of future sessions.

It's on by default in recent versions (v2.1.59+, per the docs). The first 200 lines of the memory index load into every session, and Claude pulls detailed topic files on demand.

Two practical things to know. First, you can just tell Claude to remember something — "remember that the API tests need a local Redis instance" — and it lands in auto memory without you editing a file. For a non-dev, that's the lowest-friction way to build persistent context: correct Claude once, out loud, and it sticks.

Second, everything is plain markdown you can read. Run /memory, open the auto memory folder, and audit what Claude has written about your project. I check mine every few weeks. Mostly it's accurate; occasionally there's a stale note from a refactor, and deleting it takes ten seconds. Treating the memory folder as something you can read and prune — rather than an invisible black box — is the difference between memory helping and memory quietly steering you wrong.

The division of labor that's emerged for me: CLAUDE.md holds the rules I'd put in a team handbook. Auto memory holds the accumulated street knowledge — the stuff you'd only know from having worked in the codebase.

Checkpoints and /rewind: the undo button nobody finds

Claude Code automatically snapshots your files before each edit it makes. Run /rewind — or press Esc twice with an empty prompt — and you get a menu of every prompt in the session. Pick one, and you can restore your code, your conversation, or both to that moment.

I went months without knowing this existed, and during those months my recovery strategy for "Claude made things worse" was asking Claude to un-make it worse. Sometimes that worked. Sometimes it compounded — the fix for the bad change introduced its own bad change, and I was three layers deep in a hole with no map. If you've lived that spiral, /rewind is the feature you were missing. One command, pick the last good point, back to safety.

The limits matter, per the checkpointing docs: checkpoints only track files Claude edited through its own tools, in the current session. Changes you made yourself in another editor aren't covered, and it's not a replacement for git — you still want real commits as your permanent history. I think of checkpoints as session-level undo and git as the save file. My actual workflow: commit before starting a chunk of work (I literally ask Claude to do it), then use /rewind freely within the session, knowing the commit is the hard floor.

There's also a subtler use: the rewind menu can restore just the conversation to an earlier point, or summarize a stretch of it, without touching files. When a session has wandered — you explored three approaches and want to get back to the decision point with your code intact — that's the move. It pairs well with the vibe coding workflow: move fast because the escape hatch exists.

Hooks, custom commands, and subagents

These three are more advanced, and I'd reach for them in this order.

Custom slash commands are prompt templates you save as markdown files in .claude/commands/. A file at .claude/commands/ship-check.md becomes /ship-check in your sessions. Anything you find yourself typing repeatedly — "review this for security issues, check the input validation, confirm no secrets are committed" — belongs in one. I keep a handful for my recurring rituals, and they've replaced a text file of prompts I used to paste from. If you've read my post on prompt engineering for non-developers, commands are where your good prompts go to become reusable.

Hooks are shell scripts that run automatically at fixed points in Claude's lifecycle — before a tool runs, after a file edit, and so on (hooks reference). The key distinction, straight from the docs: CLAUDE.md instructions are context Claude tries to follow; hooks execute regardless of what Claude decides. A PreToolUse hook can block any command touching a protected folder — not ask nicely, block. If there's a rule in your project where "Claude usually complies" isn't good enough — never touch the production env file, always run the linter after edits — that rule wants to be a hook. Writing one requires a small shell script, which sounds intimidating, but Claude will write its own hooks if you describe the rule. That still makes me smile.

Subagents are separate Claude sessions spawned to handle a task with their own context window, reporting back only the conclusion. The practical benefit for a founder: verbose work stays out of your main conversation. When Claude searches forty files to answer a question, all that file-reading noise fills up context you'd rather spend on the actual work. Delegating research to a subagent keeps the main thread clean, which meaningfully delays the moment your session degrades. You don't have to configure anything to benefit — you can just ask Claude to "use a subagent to research X."

Which feature solves which problem?

Here's the map I wish someone had handed me:

Problem you have	Feature	Effort to adopt
Claude changes things I didn't want changed	Plan mode (Shift+Tab)	None — it's a keystroke
I re-explain my project every session	CLAUDE.md + `/init`	~30 minutes once
Claude forgot what we figured out last week	Auto memory	None — on by default
Claude made it worse and I can't get back	`/rewind` / double-Esc	None — it's a command
I type the same long prompt every week	Custom slash commands	~10 minutes per command
A rule keeps getting ignored	Hooks	Small script (Claude can write it)
Long sessions get dumb and forgetful	`/context`, `/compact`, subagents	Habit, not setup

The last row deserves a word since it's the only one I haven't covered: /context shows you what's filling Claude's context window, and /compact compresses the conversation when it gets bloated. Sessions don't fail loudly when context fills up — they just get subtly worse. Checking /context when a long session starts feeling off is the diagnostic most people never run.

If you're comparing tools rather than deepening one, my Cursor vs Claude Code vs Cowork comparison covers where each fits. But the honest takeaway from writing this post: most people don't need a different tool. They need the second half of the one they have.

Frequently asked questions

What's the difference between CLAUDE.md and auto memory?

CLAUDE.md is written by you and holds instructions and rules; auto memory is written by Claude and holds learnings it picks up from working with you. Both load at the start of every session. Instructions set the standard; memory accumulates the context.

Do checkpoints replace git?

No. Checkpoints only track files Claude edited in the current session, and they're a session-level safety net, not permanent history. Keep committing to git — or ask Claude to commit for you at sensible points — and use /rewind for the in-session mistakes between commits.

Are hooks safe for a non-developer to set up?

Reasonably, if you start with read-only or blocking hooks (ones that prevent actions rather than perform them). Describe the rule you want enforced and have Claude write the hook script, then have it explain the script back to you line by line before you enable it.

How big should a CLAUDE.md file be?

Under 200 lines, per Anthropic's own guidance — adherence drops as the file grows. If you're past that, move path-specific instructions into .claude/rules/ files that only load when relevant files are touched.

Do these features exist in Cursor or other AI tools?

Partially. Most AI coding tools have some instructions-file equivalent (Cursor has rules files), and several have plan-like modes. The specific mechanics here — auto memory, /rewind, lifecycle hooks — are Claude Code features, though the concepts transfer.

Which feature should a beginner adopt first?

Plan mode, same day you install. Then CLAUDE.md within the first week. Everything else can wait until you feel the specific pain it solves — adopting features before the pain exists just adds complexity.

Conclusion

The pattern across all eight features is the same: Claude Code ships with the guardrails non-tech founders need, but they're opt-in, and nothing forces you to find them. Plan mode gives you review before damage. CLAUDE.md and auto memory give you continuity. Checkpoints give you undo. Hooks give you enforcement. None of them require engineering skill to use — they require knowing they exist, which is the gap this post is meant to close. Start with plan mode and a CLAUDE.md this week; add the rest when the matching pain shows up. These Claude Code features tips are most of the distance between fighting the tool and working with it.

If you're shipping a SaaS with AI coding tools, Coding Capybaras is the free boilerplate I built for exactly this workflow — it ships with a CLAUDE.md already written, so the guardrails in this post are configured before your first session.

Stripe Webhook Hell: Every Gotcha (and How to Avoid It)

Justin W Boggs — Tue, 21 Jul 2026 20:28:56 +0000

Photo by SumUp on Unsplash

Stripe webhooks are where most indie SaaS founders meet their first truly nasty bug, and it's almost always one of four things: a signature that won't verify because a framework mangled the request body, a missing idempotency check that double-charges or double-fulfills, a handler that runs too slow and gets retried into a storm, or a dev-vs-prod config mismatch where events silently vanish. None of these throw a loud error. They fail quietly, in production, on the code that touches your customers' money — which is exactly why they're so painful. The good news: every one of them has a known fix, and once you understand why each gotcha happens, they stop being mysterious. Here's the full tour.

TL;DR

Verify the signature, and use the raw body to do it. Stripe signs every event; if your framework parses the body to JSON before you verify, verification fails. This is the #1 cause of "my webhook won't work."

Make your handler idempotent. Stripe guarantees at-least-once delivery and retries for up to 72 hours, so the same event can arrive more than once. Store each event.id with a unique constraint and skip duplicates.

Return a 2xx fast, then do the work. Stripe expects a quick success response and retries anything else. Verify, enqueue the event, return 200 — don't send email or sync an ERP inline.

Dev and prod are different worlds. Separate signing secrets, separate endpoints, and the Stripe CLI for local testing. Mixing them up is how events disappear silently.

This is the highest-stakes code you own. Treat the webhook handler as core infrastructure, not a glue script.

Why are webhooks so error-prone in the first place?

A webhook is just Stripe making an HTTP request to your server when something happens — a payment succeeds, a subscription renews, a card gets declined. Conceptually it's simple. The reason it turns into "hell" is that a webhook is an event you don't control the timing, ordering, or delivery count of. Everything else in your app, you trigger. A webhook arrives whenever Stripe decides, possibly more than once, possibly out of order, possibly while your server is mid-deploy.

That inversion breaks the assumptions most founders code with. You write a handler imagining it runs once, cleanly, right after the customer pays. In reality it might run three times, the third arriving eleven hours later, after a retry, while a different event for the same customer is also in flight. Code that's correct for the happy path is quietly wrong for the real one.

And the failures are silent. A bug in your checkout page throws an error the customer sees. A bug in your webhook handler just means a customer paid and never got access — and you find out days later from a support email. That's what makes this the part of a Stripe integration worth slowing down on. In the boilerplate, all of this lives in one file (/platform/lib/payments/webhook-handler.ts) on purpose: the money-touching logic is concentrated in one place you can reason about, not scattered across routes.

The four sections below are the four gotchas, in the order you'll typically hit them.

Gotcha 1: Signature verification and the raw body trap

Stripe signs every webhook so you can prove the request actually came from Stripe and wasn't forged. Per Stripe's webhook documentation, each event arrives with a Stripe-Signature header, and you verify it with the Stripe library before trusting a single byte of the payload. Skip this and an attacker can POST a fake payment_intent.succeeded to your endpoint and unlock paid features for free. Verification is not optional — it's the security boundary of your whole billing system.

Here's the trap that gets nearly everyone: signature verification needs the raw request body, exactly as Stripe sent it. Most web frameworks — including Next.js by default — automatically parse incoming request bodies into JSON for you. That convenience destroys the signature. Stripe computed its signature over the original bytes; the moment your framework re-serializes the parsed object, even a whitespace difference makes the computed signature not match, and verification fails with a cryptic error that has nothing to do with the real cause.

The fix is to tell your framework not to parse the body for the webhook route, and to hand Stripe the raw buffer. In a Next.js App Router route handler you read await request.text() and pass that string straight to stripe.webhooks.constructEvent() along with the signature header and your signing secret. Get those three inputs right — raw body, signature header, correct secret — and verification just works.

The other half of signature verification is replay protection. Stripe includes a timestamp in the signed payload, and the official libraries reject anything older than a 5-minute default tolerance (per Stripe). That stops an attacker from capturing a valid old event and replaying it later. You rarely need to touch the tolerance — just know it's why a webhook replayed from a log hours later will fail verification, which is by design, not a bug.

If verification is failing, the debugging order is almost always: (1) am I using the raw body, (2) is the signing secret the right one for this endpoint, (3) is the signature header being passed through unmodified. Ninety percent of the time it's number one.

Gotcha 2: Idempotency, or why the same event arrives twice

Stripe guarantees at-least-once delivery. Read that carefully — at least once, not exactly once. The same event can, and eventually will, be delivered to your endpoint more than one time. This happens because of retries (more on those next), network hiccups, and Stripe's own redundancy. If your handler isn't built for it, the duplicate is a real bug with real money attached.

Picture a checkout.session.completed handler that grants a license and emails a download link. It runs once, all good. Then the same event arrives again. Now you've granted two licenses and sent two emails — or worse, if the handler creates a record, you have a duplicate. For a refund or a credit, a double-processed event is money straight out the door.

The fix is idempotency: process each event exactly once, no matter how many times it's delivered. The standard pattern, recommended across Stripe integration guides, is to store every processed event.id in a database table with a UNIQUE constraint. At the top of your handler, try to record the event ID; if it's already there, you've seen this event — return 200 and stop. If it's new, do the work.

The subtle part most tutorials skip: the idempotency record and the actual business logic must commit in the same database transaction. If you mark the event as processed before doing the work and your server crashes in between, the retry sees the ID, thinks it's done, and skips it — so the customer paid and never got access. If you do the work first and crash before recording the ID, the retry runs the work again — double-fulfillment. Wrapping both in one transaction is what makes "exactly once" actually hold. This is also why the database you pick matters here: you want real transactional guarantees under your billing logic, not eventual consistency.

Gotcha 3: Retries, timeouts, and the storm you cause yourself

Stripe decides whether a delivery succeeded based purely on your HTTP status code. Any 2xx response is success; anything else — a 400, a 500, a redirect, or a timeout — is a failure that triggers a retry. And Stripe doesn't retry gently. In live mode it retries with exponential backoff for up to three days, across roughly 16 attempts (per Stripe's documentation): the first retry within an hour, then spacing out to twice a day, then daily until it gives up.

The chart shows why a slow or flaky handler is so dangerous: every failure schedules another delivery, and those stack up. If your handler is slow enough to time out — Stripe waits only about 10 seconds for a response — every single event "fails" from Stripe's view and gets retried, even though your code eventually finished. Now you've got the original event plus a retry running the same expensive work, racing each other, multiplying load exactly when your server is already struggling. That's the self-inflicted storm.

The fix flips the order of operations. Verify the signature, immediately persist or enqueue the event, return 200 — and only then do the slow work. Sending email, syncing to another system, generating a PDF: none of that belongs inline in the webhook response. Acknowledge fast so Stripe is satisfied, then process the event from a background job or a queue. This is exactly the kind of long-running work that pushed me toward a backend platform that can run workers — serverless functions are fine for the fast acknowledgment, but the heavy processing wants somewhere it can take its time.

If you do hit failures, don't panic-rebuild — Stripe's dashboard shows every delivery attempt and its response, and you can manually re-send any event. That visibility, plus good logging in your error tracker, turns webhook debugging from guesswork into reading a clear record of what arrived and what your code did with it.

Gotcha 4: The dev-vs-prod traps that swallow events

The last category isn't a coding bug — it's a configuration bug, and it's the one that makes people think Stripe itself is broken. Dev and prod are completely separate worlds in Stripe, and mixing them up makes events silently vanish.

The biggest offender is the signing secret. Every webhook endpoint has its own secret, and your local testing setup has a different secret again. Deploy with the test-mode secret in your production environment, or paste your local secret into prod, and every real event fails signature verification. No crash, no alert — just verification failures piling up while customers pay and get nothing. Each environment needs its own endpoint and its own secret, loaded from that environment's config, never hardcoded. (In the boilerplate, like every secret, this lives only in .env.local and the deploy platform's env vars — never in the code.)

For local development, the right tool is the Stripe CLI. Running stripe listen --forward-to localhost:3000/api/webhooks opens a secure tunnel from Stripe to your machine and prints a dedicated webhook signing secret for that session. You can then stripe trigger checkout.session.completed to fire real test events at your local handler. This is how you test webhooks without deploying — and without it, people resort to clicking through real checkouts on a deployed test build, which is slow and miserable.

A few more environment traps worth knowing. Test-mode events and live-mode events are entirely separate streams; a test purchase never hits your live endpoint and vice versa, so "it worked in test but not in prod" is usually a secret or endpoint mismatch. And if your webhook route sits behind authentication middleware, Stripe's request — which carries no login session — gets blocked before your handler runs, so the webhook path must be explicitly public. The reliability of these events is the backbone of everything downstream, from access control to receipts to your lifecycle email sequences — a dropped subscription.updated is a customer who keeps access after canceling, or loses it after paying.

Frequently asked questions

Why does my Stripe webhook signature verification keep failing?

The most common cause is that your framework parsed the request body before you verified it. Signature verification requires the raw, unmodified body exactly as Stripe sent it. In Next.js, read the raw body with await request.text() and disable automatic body parsing for the webhook route. The second most common cause is using the wrong signing secret for that endpoint or environment.

What does idempotency mean for Stripe webhooks?

It means processing each event exactly once even though Stripe may deliver it multiple times (at-least-once delivery). Store every event.id in a database table with a unique constraint, and skip events you've already recorded. Critically, commit the idempotency record and the business logic in the same transaction so a crash between them can't cause double-fulfillment or a missed event.

How long does Stripe retry a failed webhook?

In live mode, Stripe retries with exponential backoff for up to three days, across roughly 16 attempts — the first within an hour, then spreading out to daily. It treats any non-2xx response, or a timeout (it waits about 10 seconds), as a failure. You can also manually re-send any event from the Stripe dashboard.

Should I do work inside the webhook handler or return 200 first?

Return a 2xx response as fast as possible, then do the slow work. Verify the signature, persist or enqueue the event, and respond 200 immediately. Running email sends, external API calls, or heavy processing inline risks a timeout, which Stripe reads as a failure and retries — creating duplicate work and load right when you can least afford it.

How do I test Stripe webhooks locally?

Use the Stripe CLI. Run stripe listen --forward-to localhost:3000/api/webhooks to tunnel events to your local server; it prints a dedicated signing secret for the session. Then use stripe trigger <event> to fire test events at your handler. This lets you develop and debug without deploying or clicking through real checkouts.

Why are my production webhooks failing when local ones work?

Almost always a configuration mismatch. Each endpoint and environment has its own signing secret, and test-mode and live-mode events are separate streams. Confirm production is loading its own live signing secret, that the live endpoint URL is registered in Stripe, and that the webhook route isn't blocked by authentication middleware.

The bottom line

Stripe webhook hell isn't really about Stripe — it's about the fact that webhooks invert the assumptions you code with. You don't control when an event arrives, how many times it arrives, or what else is happening when it does. Once you internalize that, the four gotchas become a checklist: verify with the raw body, make the handler idempotent within a transaction, acknowledge fast and process in the background, and keep dev and prod cleanly separated. Get those right and the "hell" mostly evaporates.

This is the code you least want to get wrong, so treat it like the core infrastructure it is. If you're building a SaaS with AI coding tools, Coding Capybaras is the free boilerplate I built for exactly this workflow — the Stripe webhook handler ships with signature verification and idempotency already wired in, so you start from the safe version instead of debugging your way to it.

Next.js + Supabase + Stripe + Resend: The 2026 Indie SaaS Stack

Justin W Boggs — Tue, 21 Jul 2026 20:23:24 +0000

Photo by Christopher Gower on Unsplash

The four-piece indie SaaS tech stack that dominates 2026 launches — Next.js, Supabase, Stripe, and Resend — is not the only viable stack. It's the one I picked for Coding Capybaras, and the one most first-time founders shipping with AI coding tools end up with after a weekend of research. The reason isn't hype: it's that each piece collapses a category of infrastructure work that used to require its own specialist, and the four pieces compose cleanly without you writing glue code that breaks at 3 a.m. This post is a tour of each layer, what it replaces, and what it costs.

TL;DR

Next.js 15 is the framework: front-end, back-end, server actions, deploys to Vercel in one push.

Supabase is the data layer: managed Postgres, authentication, file storage, all behind one console.

Stripe handles payments, subscriptions, tax, and the customer portal; the only file in your repo that talks to Stripe is the webhook handler.

Resend is transactional email — React templates, deliverability handled, free up to 3,000 emails per month.

At zero customers, this stack costs $0/month. At 10K users with paid revenue, it lands around the low hundreds.

The four-piece stack at a glance

Think of an indie SaaS as four problems: hosting code, storing data, taking money, and sending email. Every stack you've seen — MERN, T3, the LAMP throwback — is a different answer to those four problems. The 2026 indie SaaS tech stack is the answer that asks AI coding tools to write the least glue code.

Here's the at-a-glance mapping:

Problem	Tool	What it replaces
Hosting + framework	Next.js on Vercel	Express + EC2, separate front-end repo + S3
Database + auth + storage	Supabase	Postgres on RDS, NextAuth/Clerk, S3 buckets
Payments + subscriptions + tax	Stripe	Paddle, FastSpring, custom billing schemas
Transactional email	Resend	SendGrid, Postmark, Mailgun

A working SaaS in this stack has roughly six surfaces: a marketing page, an auth flow, a paid-checkout flow, a dashboard, an admin page, and a small number of webhook handlers. Everything else is content. You don't run a server, you don't pick a queue, you don't pick a CDN. The tools have opinions about those things and they're correct opinions for a one-person company.

What this stack is not good at: heavy background processing, large file pipelines, real-time gaming, anything where you need an actual cluster. If your idea needs that, this is the wrong stack. But "founder shipping a paid B2B SaaS in 2026" is exactly what this stack is shaped like.

The rest of this post takes each piece in turn — what it does, what it doesn't do, the gotchas first-time founders hit, and what it costs as you grow. I'll stay honest about the rough edges; the goal is for you to make this choice with eyes open, not to upsell you.

Next.js 15: the front-end and the back-end in one file tree

Next.js 15 with the App Router is the framework. Calling it a "front-end framework" undersells it: you write React pages, server components, and server actions in the same file tree, and the framework decides what runs in the browser and what runs on the server. For a non-tech founder, that's the single most important property of the stack — you stop choosing where code "lives" and start writing features.

Server actions are the unlock. In Next.js 15, you write a function, slap "use server" on it, and call it from a form on the client. Next.js generates the API endpoint, validates the call, and runs the function on the server with your database credentials in scope. There is no /api/create-thing.ts file you have to remember to write, no fetch call that gets the parameter shape wrong. The Next.js team has spent the last year hardening that surface — security improvements in 15 include unguessable action endpoints and origin checks for CSRF, which used to be on your shoulders.

You deploy this to Vercel with one push to GitHub. The Hobby (free) plan gets you a real production deploy with HTTPS, automatic preview environments per pull request, 100 GB of bandwidth, 100,000 function invocations, and 1 million edge requests per month, per the official Vercel limits page. The license restriction matters: Hobby is non-commercial only, so the moment you take a paying customer you graduate to the $20/month Pro plan. Plan for that line item from day one — it's not optional once you're a business.

Where you'll get bitten: client components vs. server components is a real mental model, not a buzzword. Anything that uses useState, useEffect, or browser APIs has to be in a file marked "use client". Anything that talks to your database, reads secrets from environment variables, or runs trusted logic stays a server component. Mix them up and you'll either leak server data to the browser or get a build error you don't understand. AI coding tools usually get this right if you describe the page in plain English ("this is a form that posts to the server and shows a success message") — but verify the file boundaries before shipping.

The Next.js docs are the source of truth here, and they're unusually good. Read the App Router section once before you start; it'll save you a weekend of confusion.

Supabase: Postgres, auth, and storage behind one console

Supabase is the data layer. Three things live behind one URL: a managed Postgres database, an auth service that handles sign-up, sign-in, password reset, and OAuth, and a file storage layer that's S3 underneath. The reason this matters for indie founders is that each of those was a separate vendor in 2019 and is now one console.

The Postgres database is real Postgres, not a managed key-value store with SQL on top. You write SQL or use an ORM (Drizzle is what I use; Drizzle vs. Prisma is its own decision and both are fine). Row Level Security policies — the rules that say "user A can only read rows where user_id = A" — live in the database, which means a bug in your application code can't accidentally hand the wrong user's data to the browser. That's the safety property that makes Supabase appropriate for a one-person operation.

The auth piece is the one most founders underweight when they pick a stack. Wiring email/password, magic link, Google OAuth, GitHub OAuth, password reset, session refresh, and "remember me" by hand is at least two weekends. Supabase Auth gives you all of it behind a configuration screen. You write one callback route at /auth/callback and you're done.

The free tier, per the Supabase pricing page, gives you two projects with 500 MB of database storage, 1 GB of file storage, 50,000 monthly active users for auth, and 500,000 edge function invocations. That's enough to launch and earn your first 1,000 users without paying. The catch — and you will hit it — is that free projects pause after one week of inactivity and the free tier has no automatic backups. For a real product, the $25/month Pro plan is correct from day one of paying customers; the daily backups alone justify it.

Where you'll get bitten: the three-clients pattern in Next.js 15. You need a Supabase client for browser code, a separate client for server components and server actions, and a third "service role" client for admin tasks that bypass RLS. Get those mixed up and you'll either expose admin powers to the browser or fail to write to the database from a server action. Every Supabase + Next.js boilerplate has its own opinion on this; copy the pattern, don't invent yours.

If you're choosing between Supabase and the alternatives, Supabase vs. Firebase is its own decision worth a separate post — Supabase wins for SaaS with rows, Firebase wins for mobile-first real-time apps. For the indie SaaS shape, Supabase is the safer default.

Stripe: payments, subscriptions, and the customer portal

Stripe is the payments layer. It is the boring, correct answer for an indie SaaS in 2026, and you shouldn't think too hard about it. Stripe's standard US online card rate is 2.9% + 30¢ per successful charge, with no setup fees and no monthly fees. If you sell subscriptions, the Billing add-on charges an additional 0.7% of billing volume for the recurring infrastructure — subscription schedules, proration, dunning, the customer portal.

What you actually get for those fees is the part that's hard to value until you've tried to build it yourself: PCI compliance is on Stripe's side, the hosted checkout page handles a hundred currencies and tax forms, the customer portal lets your users cancel or upgrade their own subscriptions without a support ticket, and Stripe Tax (an additional fee) handles VAT and US sales tax registration for you. If you've ever read someone's "I tried to handle EU VAT myself" thread on X, you know what you're buying.

Three rules for Stripe in a Next.js app, in order of how badly each one will burn you if you ignore it:

The Stripe SDK gets imported in exactly one file. In Coding Capybaras that's /platform/lib/payments/stripe.ts. Every other file calls a thin abstraction layer. This sounds pedantic until you want to swap Stripe for Lemon Squeezy in two years.
Verify webhook signatures. Stripe sends a Stripe-Signature header on every webhook. If you skip the verification, anyone on the internet can hit your webhook endpoint with a fake "subscription canceled" event and lock real customers out of their accounts. The signature check is six lines of code. Write them.
Webhook handlers must be idempotent. Stripe will retry events. Your handler will see the same customer.subscription.updated event twice. Store the event ID, check for duplicates, no-op the second time. If you skip this, you'll grant double credits, send double receipts, and explain it to your first ten paying customers individually.

The Coding Capybaras boilerplate gets the webhook plumbing right out of the box — that's specifically the part I wanted to never have to think about again. If you're choosing how to ship payments today, the Coding Capybaras boilerplate comparison post walks through how the four major options handle this. Stripe vs. Lemon Squeezy vs. Paddle is the other branch of this decision — Stripe wins for the US-centric, dev-experience-first founder; Paddle wins for the EU founder who wants merchant-of-record handling.

What you'll get bitten by: dev vs. prod webhook secrets. They're different. The Stripe CLI's stripe listen command generates a fresh secret for your local environment that won't work in production. Keep both in .env.local and .env.production respectively, and never let a deploy ship with the dev secret.

Resend: transactional email without the deliverability tax

Resend is the email layer. Welcome emails, password resets, payment receipts, "your subscription is expiring" — all transactional, all going through one provider, all logged in your own database so you can prove what was sent when.

The Resend free tier gives you 3,000 emails per month and 100 per day. The Pro plan is $20/month for 50,000 emails. Both include React Email, which is the actual reason Resend won the indie SaaS bracket in 2025 — you write email templates as React components in the same repo as your app, with the same TypeScript types. There is no separate template editor, no "preview in Outlook" tab. The same component you preview in the Next.js dev server is the one that gets sent.

Why this matters: every founder I know has lost a half-day to a Postmark template that didn't render right in Gmail, or to a SendGrid template that broke when the marketing team renamed a merge tag. React Email moves the templates into the file tree, where your AI coding tool can read them and your linter can yell about typos. The deliverability infrastructure — SPF, DKIM, DMARC, IP warm-up, multi-region sending — Resend handles in the background. You buy a custom domain, paste three DNS records into your registrar, and email starts arriving in inboxes.

The pattern I use in the boilerplate: every transactional send goes through one helper function (sendEmail()), and that helper writes a row to a platform_email_log table before calling Resend. When a customer says "I never got the receipt," you check the log first, see whether Resend accepted the message, and only then dig into the user's spam folder. Founder support gets significantly less frustrating when you can prove what was actually sent.

What you'll get bitten by: domain verification can take up to 48 hours after you add DNS records (it's usually minutes, but the long tail exists). Set this up the same day you set up your Stripe account, not the morning of your launch.

If you're comparing Resend to alternatives, the Coding Capybaras blog post on the file-based blog system is a good example of how I treat email-template files the same way I treat blog-post files — version-controlled, in the repo, deployable with a git push. The deeper Resend vs. Postmark vs. Mailgun comparison is its own post; the short version is that Resend wins for an indie SaaS that writes templates in code, Postmark wins for a team that wants a UI editor, and Mailgun wins on raw scale.

What this stack actually costs from $0 to 10K users

The honest cost picture, end-to-end:

Stage	Hosting	Database	Payments	Email	Total
Pre-launch (0 users)	Vercel Hobby ($0)	Supabase Free ($0)	Stripe ($0)	Resend Free ($0)	$0/mo
First paying customer	Vercel Pro ($20)	Supabase Free ($0)	~3% of revenue	Resend Free ($0)	~$23/mo
1,000 users, paid	Vercel Pro ($20)	Supabase Pro ($25)	~3% of revenue	Resend Free ($0)	~$74/mo
10,000 users, paid	Vercel Pro ($20)	Supabase Pro ($25)	~3% of revenue	Resend Pro ($20)	~$355/mo

A few honest caveats on that table. Stripe's percentage isn't a fixed cost — it's a fee on revenue, and the line above is a back-of-envelope at $1,000/month MRR scaling to ~$10K MRR. The day you take your first paying customer is the day Vercel Hobby's non-commercial license stops applying — graduate to Pro. The Supabase free tier is genuinely usable for a paid product technically, but the lack of backups is the wrong gamble. None of these numbers include domain registration ($12/year), Stripe Tax (a per-jurisdiction fee that's worth it the day you have international revenue), or Sentry/PostHog/analytics — those are separate marketplace decisions.

If you want the line-item version with usage caveats, the Vercel limits documentation and the Supabase pricing page are the canonical sources. I update the numbers in the Coding Capybaras integration marketplace whenever the providers change them.

Frequently asked questions

Is Next.js really the right framework for a non-tech founder?

For a SaaS in 2026, yes. Next.js has the largest community, the most LLM training data, and the best AI-coding-tool support of any React framework. Your AI assistant will produce working Next.js code more reliably than working Remix or SvelteKit code, simply because there are more examples for it to draw from. That community-size effect is decisive when you're not the one debugging at 2 a.m.

Can I swap Supabase for Firebase later?

You can, but it's a real migration — auth schemas differ, the database models differ, and Firebase's real-time primitives don't map cleanly to Postgres. Pick the one you'll be on in two years and commit. For most indie SaaS shapes — B2B subscription, rows of data, RLS-style permissions — Supabase is the safer pick. Firebase wins if you're building a mobile-first app with heavy real-time sync.

What if Stripe isn't available in my country?

Stripe is live in 47+ countries as of 2026. If yours isn't on the list, Paddle or Lemon Squeezy are the merchant-of-record alternatives — they handle the legal entity that takes the money on your behalf, in exchange for a higher fee. You give up Stripe's developer experience and you pick up tax compliance. Whether that's worth it depends entirely on your geography.

Do I really need Resend if Supabase Auth sends emails?

Supabase Auth sends transactional emails (sign-up confirmation, password reset) on its own infrastructure, which is fine for those specific flows. The moment you want to send anything else — receipts, lifecycle emails, "your trial expires in three days" — you need a real email provider. Resend is the cheapest correct answer; Postmark is the next step up if you want a UI template editor.

Is this stack overkill for a side project I haven't validated yet?

It costs $0 to find out. The free tiers of all four services let you build a real, working SaaS, take a real payment, and email a real customer without spending a dollar on infrastructure. The "overkill" question shows up after launch, when you're paying $355/month for 10K users — and at that point you have revenue.

Should I learn this stack myself or have AI write it?

Both, in that order. Have the AI assistant write the first version so you can ship something. Read the code it produces. Ask why it made each decision. By the third feature you'll know enough Next.js to debug what your AI assistant gets wrong — and that's the point at which AI coding stops being a parlor trick and starts being a real engineering multiplier.

The honest take

This stack works because the four pieces have spent the last three years getting better at the same problem from different angles. Next.js made the framework decision easier. Supabase made the database/auth decision easier. Stripe was already the boring correct answer for payments. Resend brought email into the file tree where it belongs. None of them are the only viable choice for their layer — they're the layer-best choices for a founder shipping a paid B2B SaaS with AI coding tools in 2026.

If you're building exactly that shape of company, Coding Capybaras is the free boilerplate I built around this stack — every piece wired up, AI rule files in every region, GUI for the configuration most boilerplates make you edit in code. The complete codebase ships free.