Tech Stack Selection Criteria for Solo Developers

Dev
ยทDante Chun

Introduction

Tech stack selection can determine a project's success or failure. Especially when developing alone, wrong choices directly lead to decreased productivity and maintenance hell.

Running a one-person development agency for 5 years, going through dozens of projects, I've developed my own tech stack selection criteria. Not just "I heard this is good," but actually verified principles.

Core Principle: "Choose Boring Technology"

This phrase comes from Dan McKinley's famous article "Choose Boring Technology." It didn't resonate at first, but after several failures, I felt it deeply.

The Trap of New Technology

In 2022, I introduced a newly released technology A to a client project. I was tempted by an article saying "This will double your development speed!"

The result?

  • Poor official documentation increased debugging time
  • When encountering bugs, no Stack Overflow results
  • Major version updates required complete code rewrite

I ended up rewriting with existing technology. A waste of time.

Advantages of Boring Technology

On the other hand, "boring" technologies like React, Node.js, PostgreSQL:

  • Solutions can be found through search when problems occur
  • Mature ecosystem with necessary libraries available
  • Long-term support is guaranteed

When developing alone, minimize time spent solving problems. Experiment with new tech when you have a team.

My Criterion 1: Unify with One Language

Full-Stack JavaScript/TypeScript

Writing frontend and backend in different languages creates context switching costs. When developing alone, this is fatal.

โŒ Combinations to avoid
- React (JavaScript) + Django (Python) + PostgreSQL
- Vue (JavaScript) + Spring (Java) + MySQL

โœ… My combination
- Next.js (TypeScript) + NestJS (TypeScript) + PostgreSQL

Using the same language:

  • Types can be shared between frontend/backend
  • Copy-paste code is possible
  • Build tools can be unified
  • No learning curve

Exception Cases

Of course, there are exceptions. When clients require specific tech stacks, or when different languages are needed for performance. But when I have a choice, I always choose TypeScript.

My Criterion 2: Minimize Management Points

Use Managed Services

I don't want to spend time on infrastructure management. Even if it costs more, I use managed services.

My choices:
- Database: Vercel Postgres, Supabase, PlanetScale
- Hosting: Vercel, Railway
- File storage: Vercel Blob, Cloudflare R2
- Auth: NextAuth.js (instead of building from scratch)

If you manage servers yourself, SSL renewal, security patches, backups, monitoring... these things keep holding you back.

Local Development Environment

But in development, I run what I need locally with Docker. PostgreSQL, Redis, etc. No cost, and I can develop without internet.

# docker-compose.yml
services:
  postgres:
    image: postgres:15
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: myapp
    ports:
      - "5432:5432"

My Criterion 3: Community Size

The Power of Ecosystem

When choosing technology, more important than GitHub stars is an active community.

Checklist:

  • Stack Overflow question count
  • GitHub issue response speed
  • Discord/Slack community activity
  • npm weekly downloads
  • Recent update date
Example - State Management Library Comparison
Zustand: npm weekly downloads 3M+, active issue response
MobX-State-Tree: fewer downloads, slow issue response
โ†’ Choose Zustand

Are There Alternatives?

When depending on specific technology, always think "What if this dies?" Choose technology with alternatives, or with clear migration paths.

My Criterion 4: Cost Predictability

Cost Matters for Client Projects

Unexpected costs during the maintenance phase after project completion are problematic. It leads to trust issues with clients.

Services with predictable costs:
- Vercel Pro: $20/month (covers most traffic)
- Railway: usage-based but can set limits
- Supabase: Free tier then $25/month

Services with unpredictable costs:
- AWS pay-as-you-go (traffic explosion = billing explosion)
- Per-hour billing VMs (keeps charging while on)

Use Free Tiers for Personal Projects

For personal or side projects, I actively use free tiers. Vercel Hobby, Supabase Free, Cloudflare free plan combination allows $0/month operation.

My Criterion 5: Exit Possibility

Beware of Vendor Lock-in

Being locked to specific platforms makes future migration difficult.

High lock-in risk:
- Firebase Realtime Database (unique structure)
- AWS Lambda + API Gateway + DynamoDB combination
- Vercel's Edge Functions (non-standard API)

Low lock-in risk:
- PostgreSQL (can host anywhere)
- Standard Node.js (Express, Fastify, etc.)
- Docker containers (can run anywhere)

Migration Experience

I've actually moved from Vercel to Railway, and from Supabase to self-hosted PostgreSQL. Because I used PostgreSQL, data migration was simple with pg_dump/pg_restore.

My Current Stack

My default stack as of 2025:

Frontend:
- Next.js (App Router)
- TypeScript
- Tailwind CSS
- React Query (server state)
- Zustand (client state)

Backend:
- Next.js API Routes (simple cases)
- NestJS (complex cases)
- Prisma
- PostgreSQL

Infrastructure:
- Vercel (hosting)
- Docker (local development)
- GitHub Actions (CI/CD)

Tools:
- VS Code
- pnpm
- Cursor (AI assistance)

I don't deviate much from this stack for new projects. Start quickly with familiar tools, add new things only when needed.

Conclusion

Tech stack selection for solo developers is a survival strategy.

More important than the latest, coolest technology:

  • Can you solve problems quickly?
  • Can you maintain it alone?
  • Can you predict costs?
  • Can you move elsewhere if needed?

If you choose technology that passes these criteria, at least your project won't fail because of technology.

If you're curious about new tech, experiment in personal projects first. Client projects use proven stacks.

๋‹ค๋ฅธ ๊ธ€