How I Choose Tech Stacks for Early-Stage Products

Every new project starts with the same question: what technology should I use? After shipping four products (NsideOut, PAM, Overdrafty, and FightNightFantasy), I've developed a framework that helps me decide quickly and confidently.

"The best tech stack is the one that lets you ship. Perfect technology choices don't matter if the product never launches."

The Framework: SPEED

I evaluate every technology choice against five criteria:

Let me break down each factor with real examples.

S — Skills I Already Have

Learning new technology takes time. For early-stage products, time is the most precious resource. Unless there's a compelling reason to learn something new, I default to tools I know well.

For me, that means:

Frontend:     Next.js + React + TypeScript
Styling:      Tailwind CSS + Shadcn/ui
Database:     PostgreSQL (via Supabase or Neon)
Auth:         NextAuth.js or Clerk
Deployment:   Vercel

Could I build faster apps with other tools? Maybe. But the speed of my hands on familiar keyboards beats theoretical performance every time.

The Learning Tax

Every new technology comes with a "learning tax"—the time spent:

• Reading documentation
• Debugging unfamiliar error messages
• Understanding conventions and best practices
• Building mental models of how things work

For side projects and MVPs, this tax is often higher than the benefit of the "better" tool.

P — Proven in Production

I avoid bleeding-edge technology for critical paths. The cost of debugging undocumented edge cases in new frameworks isn't worth the marginal benefits.

My rule: Technology should have at least 2 years of production use by companies I respect before I adopt it for core features.

The Hype Cycle Reality

Year 1:  "This changes everything!"
Year 2:  "Here are 47 edge cases nobody mentioned"
Year 3:  "Okay, here's how to actually use this in production"
Year 4:  "Mature, documented, recommended"

I prefer to adopt at Year 3-4, not Year 1.

Exceptions

I'll use newer technology for:

• Non-critical features that can be easily replaced
• Personal learning projects
• When the new tech solves a problem nothing else can

E — Ecosystem Depth

When I hit a problem, I want to find solutions quickly. Deep ecosystems mean:

• ✅ More Stack Overflow answers
• ✅ More npm packages for common problems
• ✅ More blog posts and tutorials
• ✅ More people who've solved my specific problem
• ✅ Better IDE support and tooling

React's ecosystem is massive. That's not exciting, but it's practical. When I need a date picker, there are 50 options. When I hit a weird bug, someone's already documented the fix.

Ecosystem Comparison

Numbers are approximate and constantly changing

Solid might be technically superior in some ways, but when I'm debugging at 2 AM, I want answers fast.

E — Easy to Deploy

If deployment is complicated, I'll avoid deploying. If I avoid deploying, I'll ship slower.

My test: Can I deploy a change in under 5 minutes?

# This is my entire deployment process:
git push origin main
 
# That's it. Vercel handles the rest.

Platforms that remove deployment friction:

• Vercel — Next.js apps, zero config
• Netlify — Static sites, serverless functions
• Railway — Databases, backend services
• Supabase — Postgres + Auth + Storage

If I need to SSH into a server, configure nginx, or manage SSL certificates manually—I'm probably overcomplicating things for an early-stage product.

D — Documentation Quality

Good documentation is a multiplier. Bad documentation is a tax on every feature.

Before adopting any library, I read its docs. If they're confusing, incomplete, or outdated, I look for alternatives.

Documentation Red Flags

• 🚩 "TODO: Add docs for this feature"
• 🚩 Code examples that don't compile
• 🚩 Last updated 2+ years ago
• 🚩 Assumes knowledge the reader doesn't have
• 🚩 No search functionality

Documentation Green Flags

• ✅ Quick start that actually works
• ✅ Comprehensive API reference
• ✅ Real-world examples
• ✅ Migration guides between versions
• ✅ Active community forum or Discord

Applying the Framework

Here's how SPEED guided my recent decisions:

Database for Overdrafty

Options considered: PostgreSQL, MongoDB, PlanetScale, Turso

Decision: PostgreSQL via Supabase

Reasoning:

• S: I know Postgres deeply from years of use
• P: Most battle-tested database in existence
• E: Enormous ecosystem of tools and ORMs
• E: Supabase makes deployment trivial
• D: Postgres docs are comprehensive; Supabase docs are excellent

State Management for FightNightFantasy

Options considered: Redux, Zustand, Jotai, React Context

Decision: React Context + useReducer

Reasoning:

• S: I've used this pattern dozens of times
• P: Built into React, can't get more proven
• E: Literally every React resource covers this
• E: No additional dependencies to deploy
• D: React docs cover this extensively

Styling for NsideOut

Options considered: CSS Modules, Styled Components, Tailwind CSS, vanilla CSS

Decision: Tailwind CSS + Shadcn/ui

Reasoning:

• S: Fast with utility classes from daily use
• P: Used by Vercel, Shopify, and thousands of companies
• E: Huge ecosystem, especially Shadcn/ui components
• E: Zero runtime, deploys as regular CSS
• D: Tailwind docs are industry-leading

When to Break the Rules

The framework has exceptions:

1. Learning Projects

Sometimes the goal is learning, not shipping. My personal site doesn't need to be the fastest—it's where I experiment with new tech.

2. Hard Requirements

Some features genuinely require specific technology:

• Real-time collaboration → Probably need WebSockets or CRDTs
• Mobile app → React Native, Flutter, or native
• ML inference → Python ecosystem is unavoidable

3. Team Skills

When working with others, their skills matter too. A team of Rails experts shouldn't switch to Next.js just because I prefer it.

4. Scale Requirements

If you know you'll need to handle millions of requests, some early decisions matter more. But most products never reach that scale—premature optimization is real.

The Meta-Lesson

The best tech stack is the one that lets you ship.

Perfect technology choices don't matter if the product never launches. Make a decision, start building, and adjust if needed. That's worked for four products. It'll work for the fifth.

Quick Reference Card

Copy this framework for your own decisions:

## SPEED Framework for Tech Decisions
 
### S - Skills I Already Have
- What's my learning curve?
- Can I be productive in week 1?
 
### P - Proven in Production
- Who else uses this at scale?
- What are the known limitations?
 
### E - Ecosystem Depth
- How many packages/plugins exist?
- Can I find answers to problems quickly?
 
### E - Easy to Deploy
- Can I deploy in under 5 minutes?
- What's the ops burden?
 
### D - Documentation Quality
- Does the quick start actually work?
- Are there real-world examples?
 
### Final Check
- Am I overcomplicating this?
- What's the simplest thing that could work?

What's Your Framework?

I'd love to hear how others make these decisions. Do you have a different framework? Have you found exceptions to these rules?

The best frameworks are the ones you actually use. SPEED works for me—adapt it or create your own.