Most technical decisions are made by comparing features. Two tools go into a spreadsheet, capabilities get listed side by side, and the one with more checkmarks wins. It’s a reasonable process — and also how you end up with infrastructure that’s hard to maintain.
The decisions that age well tend to start somewhere else: with constraints.
When I chose Astro for this site, the question wasn’t which framework has the best ecosystem or the most active community. The question was simpler: what are the actual constraints of this problem, and what’s the minimum tool that satisfies them?
The constraints were clear. Static content, no dynamic backend, minimal dependencies, low operational complexity. The non-goals were equally important: no real-time features, no framework lock-in, no over-engineering a site that serves one purpose.
Astro happened to satisfy those constraints with the least friction. Content-first, minimal runtime, easy to reason about. Not because it’s the best framework — but because it was the right fit for a well-defined problem.
A tool chosen for its features will pressure you to use those features. A tool chosen for its constraints will stay out of your way.
Tools change. Constraints don’t. Most decisions that age well start with an honest definition of constraints.
Written by Miguel Hernández