The One-Stack Rule: How a Solo Builder Ships Fast Without Burning Out

When you build software alone, your scarcest resource isn't time or talent. It's decisions. Every project that makes you re-choose your database, re-learn a deploy pipeline, or re-wire authentication is a project that ships slower and costs more to maintain.

The fix is almost embarrassingly simple: pick one stack and reuse it on everything.

Why one stack wins

A single, well-worn stack gives you compounding advantages:

• Speed. You're not learning - you're assembling. The boring 40% of every build (auth, deploy, email, forms) becomes copy-paste.
• Maintainability. When every project looks the same, fixing a client's bug eighteen months later doesn't require an archaeology dig.
• Cheaper to run. You learn exactly where the cost lands and how to keep it near zero on managed, serverless infrastructure.
• Better quality. Repetition turns into polish. The tenth time you wire up Stripe, you do it right without thinking.

The cost is that you occasionally use a slightly-less-perfect tool for a job. That trade is almost always worth it. A "perfect" tool you've never used is slower than a good tool you can deploy in your sleep.

The stack I reuse

Here's the default lane I reach for on nearly every build:

• Next.js for the app and the marketing site - one framework, front and back.
• Vercel for hosting and deploys. Best-in-class Next.js support, every feature works day one.
• Neon (serverless Postgres) as the default database - branching, scale-to-zero, room to grow.
• Clerk for authentication, so I never roll my own login.
• Stripe for payments and subscriptions.
• Upstash for caching, rate limiting, and background/cron jobs (Redis + QStash).
• Cloudflare R2 for file storage - no egress fees.
• Resend for transactional email.

That covers the overwhelming majority of what a small business needs.

The one escalation rule

Discipline doesn't mean dogma. You need exactly one documented escalation path for when the default genuinely isn't enough:

Move off serverless to Railway only when the app needs an always-on process - background workers, self-hosted websockets, or long-running jobs. Before that, reach for Upstash QStash so background work stays serverless and the rest of the stack doesn't change.

One default. One escalation. That's it. The moment you have a third "it depends," you're back to making decisions on every project - which is the thing you were trying to avoid.

How to choose your own one stack

If you're assembling your own, optimize for these, in order:

1. What you already know deeply. Boring familiarity beats exciting novelty every time.
2. Managed over self-hosted. Your time is worth more than the few dollars you'd save running your own server.
3. Portability. Avoid lock-in that would make moving providers a rewrite. You want the freedom to migrate, even if you never use it.

Then write it down - literally a one-page document - and treat deviating from it as a decision that needs a reason, not a default.

Want something built on a stack that's been shipped before? Start a project and let's talk.