When a client asks me “what technology are we going to build the website with?”, the honest answer is almost never simple. Because the choice of tech stack is not a technical detail that can be delegated: it’s a strategic decision that directly affects performance, maintenance cost, and the real user experience.
Frontend Is Not Just “Painting the Interface”
There’s a widespread idea that the frontend is just the visual part: what the user sees and touches. But that view enormously underestimates what happens between the server and the browser.
Modern frontend manages:
- Load performance: How long the first screen takes to become interactive. Every second matters, especially on mobile with variable connections.
- Accessibility: Whether the content is usable by people with disabilities. It’s not an optional extra; in many contexts it’s a legal requirement.
- Technical SEO: How search engines read the generated content. Many modern frameworks require specific configuration to avoid penalizing rankings.
- Maintainability: Whether the code I write today can be maintained and evolved in the future without rewriting everything from scratch.
Why I Use Astro (And When I Don’t)
Astro is my main framework for most web projects. The core reason is simple: it generates static HTML by default, which translates into minimal load times and excellent Core Web Vitals scores.
But Astro isn’t the answer to everything. I use it when:
- The content is primarily static or semi-static (blogs, corporate websites, landing pages, portfolios).
- SEO is a strategic priority.
- Performance on mid-to-low-end devices matters.
For applications with a lot of real-time interactivity, complex client states, or advanced authentication, the choice changes. Solutions like Next.js or other specific frameworks may make more sense there.
The Real Cost of Choosing the Wrong Stack
The wrong tech stack choice is usually not visible on day one. It appears months later:
- A WordPress site with too many plugins that loads in 6 seconds on mobile.
- A React project where 80% of the work is state management and 20% is content.
- A custom CMS store that nobody can update because the original developer disappeared.
These situations have something in common: the technology was chosen for convenience, trend, or ignorance — not because it was the right fit for the problem.
The Question I Ask Before Choosing
Before proposing a stack on a project, I ask this question: Who is going to maintain this in twelve months?
If the answer is “the client alone”, the solution should be as simple as possible, with a user-friendly CMS and minimal dependencies.
If the answer is “a well-resourced development team”, we can talk about more sophisticated solutions.
If the answer is “nobody has thought about it yet”, that’s the real problem to solve before writing a single line of code.
The best frontend is the one users don’t notice because everything works exactly as expected. Invisible, fast, honest. That’s what I pursue.
Have a project in mind?
Let's talk about how I can help you achieve your goals and scale your business.