How to choose a framework: start with the problem, not the tool

How to choose a framework without starting from the framework: four steps that turn a vague need into a clear technology choice that is easy to maintain.

When a new request comes in, many developers reflexively open a browser and search for "best framework for X". That question almost always comes in the wrong order: we're choosing a solution before we understand the problem.

This post suggests a four-step process, short enough to use in one afternoon but strict enough that you can defend your choice in front of your team.

Step 1: Write the problem in your users' language

Before thinking about technology, write a short paragraph: who uses it, what they do, and what happens if the system is slow or fails. If you can't write that paragraph, you're not ready to choose a tool.

Step 2: List the real constraints

  • Who will maintain it six months from now: you, the team, or someone not hired yet?
  • What's the monthly infrastructure budget?
  • Are there SEO, offline or real-time requirements?
  • Is the deadline fixed?

Constraints rule out options faster than anything else. A two-person team with a four-week deadline shouldn't run its own Kubernetes, however good the tool is.

Step 3: Compare three options at most

Put the options in a simple table and score them against exactly the constraints from step 2. Don't score them by GitHub stars.

decision.md — a template for recording a technical decision
# Decision: choose a framework for the blog

## Context
One author, needs good SEO, a budget of almost zero.

## Options
1. Next.js + Vercel
2. Astro + Netlify
3. Self-hosted WordPress

## Conclusion
Choose (1) because the team already knows React and needs an admin area.

## Consequences
Depends on Vercel; acceptable at this early stage.

Step 4: Write it down and set a review date

A decision that isn't written down gets argued about again every quarter. Save the decision file right in the repository and set a date to review it, for example after three months in production.

The best tool is the one your team can operate at 2 a.m.

Get the next post by email.

One email a week, only when there is something worth reading. No spam.