La decisión más importante antes de escribir una línea de código
Elegir la tecnología correcta para un proyecto web no es una decisión técnica — es una decisión de negocio. El stack que elijas va a determinar la velocidad de desarrollo, los costes de mantenimiento, la escalabilidad y, en última instancia, el rendimiento de tu sitio.
He visto demasiados proyectos que empiezan con la tecnología equivocada y terminan costando el doble en tiempo y dinero. No porque la tecnología sea mala, sino porque no era la adecuada para ese caso concreto.
Después de más de 50 proyectos entregados en España y Latinoamérica, he desarrollado un framework de decisión que me permite acertar en la elección tecnológica en el 95% de los casos. Lo comparto en esta guía.
Los tres factores que deberías considerar primero
Antes de pensar en React, WordPress, Astro o cualquier otra herramienta, necesitas responder tres preguntas fundamentales:
- ¿Cuál es el objetivo principal del sitio? Un sitio corporativo informativo tiene necesidades completamente diferentes a un e-commerce con 5.000 productos o una aplicación web con usuarios registrados.
- ¿Quién va a mantener el contenido después del lanzamiento? Si tu equipo de marketing necesita autonomía total, un CMS visual es obligatorio. Si tienes un equipo técnico, puedes optar por soluciones más flexibles.
- ¿Cuál es tu presupuesto real, incluyendo mantenimiento a 12 meses? Muchos proyectos eligen tecnologías que parecen baratas al inicio pero generan costes recurrentes elevados en hosting, plugins, actualizaciones de seguridad y soporte técnico.
La tecnología debe servir al objetivo, no al revés.
Mi framework de decisión simplificado
Para sitios de contenido y marketing
Uso Astro con Markdown o un CMS headless como Sanity o Storyblok. Astro genera HTML estático, lo que significa rendimiento perfecto en Core Web Vitals sin esfuerzo extra. El resultado son páginas que cargan en menos de 1 segundo y que Google indexa sin problemas.
Para clientes que necesitan editar contenido sin depender de un desarrollador, conecto Astro con un CMS headless. El editor trabaja en una interfaz visual amigable y los cambios se publican automáticamente.
Para e-commerce
Recomiendo Shopify si el catálogo es simple (menos de 500 productos) y no se necesita personalización extrema. Shopify ofrece pasarela de pago, gestión de inventario y logística integrada por una fracción del coste de desarrollar todo custom.
Para e-commerce con requisitos avanzados — personalización de producto, múltiples monedas, integraciones complejas — opto por soluciones headless con frameworks como Next.js conectados a Shopify o Medusa como backend. Más trabajo inicial, pero mucha más flexibilidad a largo plazo.
Para aplicaciones web complejas
Cuando el proyecto requiere autenticación, datos en tiempo real, lógica de negocio compleja o paneles de administración, un framework full-stack como Next.js o Remix con una base de datos como Supabase o PostgreSQL es la mejor opción.
La clave está en no sobredimensionar: no necesitas un framework SPA para un blog, igual que no necesitas un CMS para una aplicación de gestión interna.
Rendimiento: el factor que muchos ignoran
Según el HTTP Archive, el 40% de los sitios web no pasan las métricas de Core Web Vitals. Google usa estas métricas como factor de posicionamiento, así que la tecnología que elijas tiene impacto directo en tu SEO.
En mi experiencia, los sitios construidos con generación estática (Astro, Hugo, 11ty) consistentemente obtienen puntuaciones de 95-100 en Lighthouse. Los sitios con WordPress sin optimizar suelen quedarse en 50-70. Los sitios con frameworks SPA (React puro, Angular) pueden tener problemas de SEO si no se implementa correctamente el server-side rendering.
Error común: elegir por moda, no por necesidad
El error más frecuente que veo es elegir tecnología porque “es lo que todo el mundo usa” o “es lo último”. He visto startups elegir microservicios con Kubernetes para un MVP que no tenía ni 100 usuarios. He visto agencias usar React con server-side rendering para un sitio de 5 páginas que solo necesitaba HTML estático.
La pregunta no es “¿cuál es la mejor tecnología?” sino “¿cuál es la mejor tecnología para este proyecto concreto, con este equipo y este presupuesto?”
La regla de oro: simplicidad primero
Mi consejo después de más de 50 proyectos es siempre empezar con la solución más simple que cumpla los requisitos actuales. La complejidad se puede añadir después, pero eliminarla es mucho más difícil y costoso.
Si estás en duda, elige la opción que tu equipo pueda mantener de forma autónoma. Un sitio simple que funciona bien es infinitamente mejor que un sitio complejo que nadie puede actualizar.
Mi checklist rápida antes de decidir
- ¿El equipo puede mantener esto sin mí?
- ¿Los costes de hosting y mantenimiento caben en el presupuesto a 12 meses?
- ¿La tecnología escala si el proyecto crece x10?
- ¿Hay documentación suficiente y comunidad activa?
- ¿El rendimiento cumple Core Web Vitals sin optimización extra?
Si respondiste “sí” a las cinco, probablemente estás en el camino correcto.