Foundations
Tech Stacks Explained
A tech stack is the combination of programming languages, frameworks, databases, and infrastructure your application uses. The wrong stack choice can slow development or create maintenance nightmares. The right stack makes everything smoother. Here's what matters.
The Four Layers
Every application has four main layers, and each layer has technology choices:
Front-end (what users see): React, Vue, Angular, or plain HTML/CSS/JavaScript. These are the frameworks for building the user interface in the browser.
Back-end (server logic): Node.js (JavaScript), Python, Ruby, Go, Java, PHP, Rust. This is the code that handles authentication, enforces business rules, and queries the database. Node.js and Python are the most popular for new projects.
Database (data storage): PostgreSQL, MySQL, MongoDB, Redis, DynamoDB. PostgreSQL is the default choice for most applications—it's powerful, battle-tested, and free. MongoDB is popular if your data doesn't fit neatly into tables.
Infrastructure (where it runs): AWS, Google Cloud Platform (GCP), Azure, Vercel, Railway, DigitalOcean. Most startups use one of these cloud providers. AWS is industry standard but complex. Vercel is excellent if you're using Next.js (a React framework). DigitalOcean is simpler if you want to avoid AWS complexity.
Common Stacks
MERN: MongoDB, Express (framework), React, Node.js. This is one of the most popular stacks, especially for startups. Everything is JavaScript, which means one language for the whole application. The downside is that MongoDB is less structured than PostgreSQL, so you need disciplined developers to maintain data quality.
PERN: PostgreSQL, Express, React, Node.js. Like MERN but with PostgreSQL. Many developers prefer this because PostgreSQL is more reliable for business data. Still JavaScript everywhere.
T3 Stack: TypeScript, tRPC, Next.js, Prisma, Postgres. This is what developers are moving toward. TypeScript gives you type safety (the compiler catches errors before they reach production). Next.js is a modern React framework. Prisma is an ORM (object-relational mapper) that makes database queries cleaner. PostgreSQL for data. This stack is not beginner-friendly but is powerful for teams that know what they're doing.
Python + FastAPI + PostgreSQL: Python is great for data-heavy applications and for developers who prioritize readability and getting to market fast. FastAPI is a modern Python framework that's faster than Django for many use cases. PostgreSQL for data. Good choice if your data model is complex or if you have data science requirements.
Rails (Ruby on Rails) + PostgreSQL: Ruby on Rails is famous for rapid development—you can go from concept to MVP in weeks. It's less popular now but some companies still use it because they've invested in it. Not recommended for new projects unless your team knows it well.
How to Choose Your Stack
The biggest mistake teams make is optimizing for the wrong thing. They choose a stack based on theoretical performance or because it's trendy, then hire developers who don't know it. The project slows down while developers learn. This is worse than choosing a slightly suboptimal stack that your team knows well.
Pick based on team expertise first. If you have developers who know Python, choose Python. If you have React experts, choose React. The best language is the one your team knows well. You'll move 2-3x faster.
Then optimize for the problem domain. If you're building a data-heavy application with complex queries, PostgreSQL is better than MongoDB. If you're building an API that handles millions of requests per second, Go or Rust might be better than Python. But these optimizations are secondary to team expertise.
Consider ecosystem maturity. Popular languages have larger ecosystems—more libraries, more Stack Overflow answers, more developers available for hire. Node.js and Python have huge ecosystems. Rust has a smaller but growing ecosystem. If you need something obscure, popular languages are safer.
Think about hiring. Can you find developers for this stack? Node.js, Python, and Go are easy to hire for. Haskell or Clojure are hard to hire for. If you're planning to scale, hiring ease matters.
Stack Doesn't Matter as Much as You Think
Here's a truth that might be controversial: for most applications, the stack doesn't matter that much. A well-built API in Python is not significantly slower than the same API in Go. An application in React is not significantly faster than the same application in Vue. The differences are small compared to the difference between a well-designed and a poorly-designed application.
What matters most is:
- Team expertise and productivity (this affects speed more than the language)
- Architecture decisions (good architecture beats fast languages)
- Database query optimization (a slow query wastes more time than a slow language)
- Infrastructure choices (are you running on expensive hardware or optimized servers?)
So choose a stack your team knows well, pick something with a mature ecosystem, and then stop worrying about it. The stack is not your problem—execution is.
Full Stack Comparison
| Stack | Learning Curve | Time to MVP | Team Size Needed | Best For |
|---|---|---|---|---|
| MERN | Medium | 2-3 months | 2-3 devs | Fast startup iteration |
| PERN | Medium | 2-3 months | 2-3 devs | Business logic, relational data |
| T3 Stack | High | 2-3 months | 2-3 devs | Type-safe, complex products |
| Python + FastAPI | Medium | 2-4 months | 1-2 devs | Data-heavy, quick iteration |
| Rails | Medium | 6-8 weeks | 1-2 devs | CRUD apps, speed matters |
| Go + Postgres | High | 3-4 months | 1-2 devs | High performance, scalability needed |
Database Choice
PostgreSQL is the default for most applications. It's free, open source, incredibly powerful, and handles almost every use case. Use PostgreSQL unless you have a specific reason not to.
Use MongoDB or document databases if: Your data doesn't fit into tables well (e.g., highly variable data structure, nested documents, graphs). But be careful—many teams use MongoDB and then regret it because they discover they do need relational structure and end up doing joins in application code.
Use Redis if: You need a cache or real-time data structure. Redis is not a primary database—it's a data cache. Use it alongside PostgreSQL.
Use DynamoDB if: You're deep in the AWS ecosystem and need automatic scaling. DynamoDB is simpler than managing PostgreSQL at massive scale, but it costs more and has fewer query capabilities.
Most applications use PostgreSQL for primary data and Redis for caching and real-time data. That combination has proven itself over thousands of applications.
Infrastructure Choice
AWS: The industry standard. Extremely powerful, complex, and has every service imaginable. Expensive if you don't optimize. Requires DevOps expertise or you end up paying for unused capacity. Use AWS if you need flexibility or plan to scale massively.
Google Cloud Platform (GCP): Similar to AWS but sometimes simpler. Excellent if you need machine learning or data analysis. Good pricing if you use BigQuery.
Azure: Best if you're in the Microsoft ecosystem (Windows, SQL Server, .NET).
Vercel: Specialized for Next.js applications. Incredibly simple—you deploy with a Git push. Recommended if you're using Next.js. Limited to Node.js applications.
Railway, Heroku, DigitalOcean: Simpler than AWS, more expensive at scale. Great for MVPs and small teams. You trade cost efficiency for simplicity and less configuration headaches.
For your first version, pick something simple: Railway or DigitalOcean. Don't use AWS unless you have DevOps expertise or need AWS-specific services. As you grow and optimization matters, you can migrate to AWS.
The Litmus Test
A good tech stack is one that your team can ship with confidently. All the stacks mentioned here are fine. The difference between them is incremental. Pick the one that plays to your team's strengths, has an ecosystem you trust, and then execute well.
Stack decisions shouldn't slow you down. If you're spending weeks choosing between Next.js and Nuxt, stop. Choose one and ship. You can almost always rewrite layer of an application if you need to—but the cost of not shipping is usually higher than the cost of rewriting.