There is a version of this post that is a 40-item "awesome list" of every tool we have ever opened. This is not that post. This is the stack we actually reach for when a client says "I need this live and taking payments," and we need to be shipping within the week, not evaluating vendors.
It is opinionated on purpose. A default stack you know cold beats a "perfect" stack you are learning on the client's dime.
The shape of the stack
Next.js (App Router) → UI + API in one codebase
TypeScript → the whole thing, no exceptions
Tailwind CSS → styling
Supabase → Postgres + auth + storage
Stripe → payments & subscriptions
Vercel → hosting & previews
Cloudflare → DNS, CDN, WAF, R2
Seven things. Each one removes a category of decisions so we can spend our judgment on the product, not the plumbing.
Next.js: one codebase for UI and API
We build on the App Router. Server Components mean most pages render on the server with zero client JS by default, and we opt into interactivity only where it earns its weight. Route Handlers give us API endpoints in the same repo as the UI, so there is no separate backend service to deploy, version, and keep in sync.
The practical win: a feature is one pull request. The form, the server action that writes to the database, and the Stripe call all live together. Junior and senior engineers can both hold the whole feature in their head.
TypeScript everywhere, or don't bother
We do not ship untyped JavaScript. The value is not "fewer bugs" in the abstract — it is that types are documentation that cannot rot. When the database schema, the API response, and the React props all share generated types, a breaking change lights up red in your editor before it ever reaches a user.
Supabase generates types straight from your Postgres schema. Stripe ships first-class types. The chain from database row to rendered pixel is type-checked end to end. That is the actual reason we are fast: refactoring is safe.
Tailwind for styling
Tailwind keeps styling local to the component and kills the dead-CSS problem — there is no global stylesheet slowly accreting selectors nobody dares delete. With a small set of design tokens defined once, the whole team produces consistent UI without a weekly "which gray is this" debate. Pair it with a component layer for the handful of patterns you repeat, and you move quickly without the markup turning to soup.
Supabase: Postgres that does the boring 80%
Supabase is the piece that saves the most time. You get:
- A real Postgres database — not a proprietary store you will fight to migrate off later.
- Auth (email, magic links, OAuth) wired in, with sessions that work cleanly with Next.js Server Components.
- Row Level Security so authorization lives in the database, next to the data, instead of being re-implemented in every endpoint.
- Storage for files and Realtime when you need it.
The thing to internalize about Supabase: it is Postgres. When you outgrow a convenience feature, you drop down to SQL. You are never trapped.
The one discipline it demands: take RLS seriously from day one. It is genuinely powerful and genuinely easy to misconfigure. Write the policies, then write tests that prove user A cannot read user B's rows.
Stripe for payments, full stop
We do not get clever with payments. Stripe Checkout and the Customer Portal handle the parts that are legally and financially load-bearing — card capture, SCA, tax, invoices, dunning, plan changes — and we listen to webhooks as the source of truth for subscription state. The cardinal rule: never trust the client's "payment succeeded" redirect; trust the webhook that hits your server. Reconcile subscription status into your own database from those events, and the rest of the app just reads a boolean.
Vercel for hosting and preview deploys
Every pull request gets its own preview URL. That single feature changes how clients work with us — they review the actual running feature on their phone, not a screenshot in a Slack thread. Merges to main deploy to production automatically. Rollbacks are one click. We spend zero hours on deployment infrastructure, which is exactly how much it deserves on most projects.
Cloudflare for the edge and the scary stuff
Cloudflare sits in front: DNS, caching, DDoS protection, and a WAF for the rules you do not want to hand-roll. We use R2 for large object storage when egress fees on other providers would otherwise quietly eat the margin. It is the layer that makes a small app behave like it has an ops team behind it.
What we deliberately leave out
Just as important as the stack is what is not in it on day one:
- No Kubernetes. If Vercel and Supabase cannot run it, the product is not at the scale where this conversation is worth having.
- No microservices. A modular monolith ships features faster and is easier to reason about until you have a real, measured reason to split.
- No bespoke auth. Rolling your own authentication is a way to introduce security bugs while feeling productive.
- No premature caching layer. Postgres indexes and Cloudflare's CDN solve the first two orders of magnitude.
Why this stack wins
None of these tools is exotic. That is the point. The advantage is not any single piece — it is that they compose into a single TypeScript codebase, type-checked from database to UI, deployed on every push, with payments and auth that we did not have to build.
A new engineer is productive in a day. A new feature is one reviewable pull request. And when a client asks "can we be live by Friday," the honest answer is usually yes — because we are not spending Monday choosing tools.
That is what shipping fast actually looks like. Not heroics. A boring, sharp, well-worn stack and the discipline to keep it that way.