Choosing Your Stack for Speed, Not Your Resume

You are two hours into your side project and you have not written a single line of business logic. You have been reading documentation for three different frameworks, comparing hosting platforms, evaluating whether to use TypeScript or Go, and debating yourself about database choices.

This is framework shopping, and it is one of the most effective procrastination techniques in software development. It feels productive — you are making informed decisions, evaluating trade-offs, building the right foundation. But the side project does not need a foundation. It needs to exist.

The previous post in this path covered scoping and shipping. This one covers the stack decisions that either enable fast shipping or prevent it entirely.

The Resume-Driven Development Trap

There is a seductive logic: "I want to learn Rust, so I'll build my side project in Rust." This combines two goals — learning a language and shipping a product — into one project. It sounds efficient. It is the opposite.

Learning a new language while building a project means every task takes three to ten times longer. You spend an hour fighting the borrow checker when you could have implemented the feature in fifteen minutes in a language you know. The project timeline expands. Momentum dies. The project joins the graveyard.

There is nothing wrong with learning Rust. Build a learning project for that. But if the goal is shipping a product — getting something in front of users — use the tools you already know.

The fastest stack is the one you don't have to think about. The language where the syntax is muscle memory. The framework where you know the patterns. The hosting platform where you have deployed before. Every minute spent learning infrastructure is a minute not spent building the feature that matters.

The Boring Technology Rule

Dan McKinley's "Choose Boring Technology" essay is a decade old and more relevant than ever. The argument: you have a limited budget for novelty. Every new technology you adopt — new language, new database, new framework — spends some of that budget. If you spend it on infrastructure, you have none left for the unique problems your product actually needs to solve.

Boring means proven. Boring means debuggable. Boring means the answer to your problem exists on Stack Overflow. Boring means you are not the first person to discover this bug.

For side projects, boring is not a compromise. It is a competitive advantage. PostgreSQL over the hot new distributed database. Django or Rails or Express over the framework that launched last week. Heroku or Vercel or Railway over a custom Kubernetes setup.

These choices are not exciting. They are fast. And fast is what ships.

A Decision Framework

When you must choose — and sometimes you must, especially for a new project — use this three-question filter:

Can I build the core feature in a weekend with this tool? If the answer is no because you need to learn the tool first, pick a different tool. If the answer is no because the core feature is inherently complex, simplify the feature.

Can I deploy with this tool in under an hour? Many modern platforms (Vercel, Railway, Fly.io, Render) support push-to-deploy. If your stack requires manual server setup, Dockerfile configuration, and infrastructure provisioning before you see a URL, you are optimizing for the wrong thing.

When something breaks, can I debug it without reading the source code of the framework? Mature frameworks have extensive error messages, active communities, and years of Stack Overflow answers. New frameworks have GitHub issues and Discord channels. The difference in debugging speed is measured in hours.

Specific Recommendations

These are opinionated defaults for side projects. They are not the right choice for every situation. They are the right choice when the goal is shipping fast.

For web applications: Next.js if you know React. Django if you know Python. Rails if you know Ruby. Laravel if you know PHP. ASP.NET if you know C#. Use the framework you already know, not the framework you want to learn.

For databases: PostgreSQL. For nearly every side project use case, PostgreSQL is sufficient. It handles relational data, JSON data, full-text search, and basic analytics. You do not need a separate database for each concern until you have scale that side projects almost never reach.

For hosting: Vercel for frontend and serverless. Railway or Render for backend services with databases. These platforms handle deployment, SSL, domains, and scaling. You can always migrate to AWS later if the project succeeds. You cannot recover the time lost to configuring AWS for a project that never launches.

For authentication: Use a third-party service (Auth0, Clerk, Supabase Auth) or the auth module built into your framework. Do not build authentication from scratch. It is complex, security-critical, and a solved problem. Spend your limited time on the feature that makes your project unique.

When to Break the Rule

Learn-by-building is legitimate. If the explicit goal is to learn a new technology, ignore everything above and build with whatever you want to learn. The project might not ship, and that is fine — learning was the goal.

If the side project is a stepping stone to a career change — you want to demonstrate Go experience, or you need a portfolio piece in Svelte — using the target technology is the right call. The shipping timeline extends, but the career outcome justifies it.

And if the project's core value proposition requires specific technology — a real-time multiplayer game needs a WebSocket-native framework, a machine learning product needs a Python ecosystem — use what the problem requires regardless of familiarity.

The rule is not "always use what you know." The rule is "know why you are choosing what you are choosing, and don't choose novelty by default."

The Takeaway

The fastest stack is the one you already know. The most reliable technology is the most boring. The most productive choice is the one that lets you spend your limited side project hours building the feature that matters, not learning the infrastructure that supports it.

Ship first. Optimize later. Rewrite never — or only after the project has users who would benefit from the rewrite.

---

Next in the "Shipping Side Projects" learning path: We'll cover marketing your side project without a marketing budget — how to get your first hundred users through communities, content, and the networks you already have.