Elegí boring technology en mis SaaS a propósito, y esa decisión se vuelve más fácil de defender cada año. La boring technology como decisión de SaaS no es conservadurismo por miedo: es reservar la complejidad para donde realmente importa. Hoy tomaría la misma decisión por una razón adicional: los agentes de IA trabajan mejor sobre tecnología común, documentada y repetida en millones de proyectos reales.
Cuando Claude o Cursor generan código para Next.js, el output es correcto en 3 veces más casos que para frameworks experimentales. Los frameworks aburridos tienen entre 5 y 15 años de Stack Overflow answers — eso se traduce directamente en menos correcciones. En mis 6 SaaS, usar stacks bien documentados redujo el tiempo de debugging de problemas de infraestructura en más del 50 por ciento de los casos.
El argumento para la tecnología aburrida
Tres condiciones bajo las cuales adopto tecnología no aburrida:
- El problema genuinamente no tiene solución en tecnología establecida — no "es más elegante", sino que no existe la solución.
- La comunidad tiene al menos 2 años de uso en producción real, no solo demos y tutoriales.
- El autor tiene historial de soporte a largo plazo — sin proyectos con último commit hace 6 meses.
La industria del software celebra la novedad. Cada año hay un nuevo framework, una nueva base de datos, un nuevo paradigma que va a resolver los problemas del anterior. La presión para adoptar lo nuevo es constante.
En SaaS, esa presión tiene un costo concreto. Cada tecnología nueva que adoptás es:
- Una curva de aprendizaje que tu equipo tiene que absorber.
- Documentación incompleta o desactualizada cuando encontrás casos edge.
- Menos respuestas en Stack Overflow, menos ejemplos en GitHub.
- Un agente de IA con menos contexto de entrenamiento para hacer cambios seguros.
La tecnología aburrida no tiene esos costos. Next.js, TypeScript, PostgreSQL/PlanetScale, Tailwind: hay millones de proyectos, miles de horas de documentación, una comunidad que ya encontró los edge cases que vos vas a encontrar.
Qué significa "aburrido" en la práctica
| Tecnología | Años en producción | Por qué "aburrida" gana |
|---|---|---|
| Next.js | 7 años | Documentación completa, Vercel first-class support |
| MySQL/PlanetScale | 25+ años | Cero sorpresas, ACID, conocido universalmente |
| TypeScript | 12 años | Type safety obligatoria en era de AI coding |
| Tailwind CSS | 5 años | Utility-first maduro con ecosistema de UI kits |
| Node.js | 15 años | Mismo lenguaje en frontend y backend |
Aburrido no significa desactualizado. Significa probado y estable en el contexto de producción real.
Next.js App Router es la última versión de Next.js. No es viejo: es el estándar actual y tiene millones de proyectos en producción. Eso lo hace aburrido en el buen sentido.
Un nuevo meta-framework que salió hace seis meses puede ser técnicamente superior en algunos aspectos y todavía no ser aburrido: no hay suficiente contexto acumulado en producción, en documentación, en entrenamiento de agentes.
La pregunta no es "¿esto es nuevo o viejo?". Es "¿hay suficiente contexto acumulado para que yo, mi equipo y los agentes que operan sobre este sistema puedan trabajar bien con él?".
Boring technology y agentes de IA
Esta es la razón que más solidifica la decisión en 2025-2026. Los agentes de IA tienen contexto de entrenamiento sobre las tecnologías más usadas. Un agente que trabaja sobre Next.js App Router puede hacer cambios seguros con menos supervisión que uno que trabaja sobre un framework de nicho.
Cada vez que elijo tecnología aburrida, estoy eligiendo también que los agentes que operan sobre mi codebase tengan más contexto y cometan menos errores.
Esto es coherente con la decisión central del cluster: la arquitectura SaaS convencional vs innovadora. El stack aburrido es la implementación de ese principio en la elección de herramientas, y se complementa con el stack AI-native 2026.
El costo real de no elegir boring technology
Es difícil ver el costo de la tecnología novedosa en el momento de adoptarla. Al principio se siente como precisión, como una herramienta que encaja mejor con el problema. El costo aparece después, cuando tenés que buscar ayuda y la documentación tiene tres años, cuando hay un bug que no está en Stack Overflow, cuando onboarding a un dev nuevo requiere explicarle convenciones que no existen en ningún manual.
También hay un costo de operación con agentes. Un agente que trabaja sobre un framework de nicho puede producir cambios plausibles que no respetan las convenciones del framework, porque las convenciones no estaban bien representadas en su entrenamiento. Ese tipo de error es difícil de detectar hasta que el sistema falla en producción.
En un SaaS operado por equipos chicos o por founders solos, ese costo de operación se siente directamente. No hay nadie más absorbiendo el conocimiento específico de la herramienta. Si te vas de vacaciones y el sistema tiene un problema, querés que cualquier agente o developer pueda entender qué pasa sin que vos estés.
Cuándo sí adopto tecnología nueva
No es que nunca adopte nada nuevo. La pregunta es cuándo el beneficio justifica el costo de operar algo con menos contexto acumulado.
Adopté PlanetScale cuando todavía era relativamente nuevo porque el problema que resolvía —branch-based schema migrations para multi-tenant— no tenía una alternativa igualmente buena. El costo de aprender algo nuevo fue menor que el costo de convivir con el problema que resolvía.
Ese es el criterio: ¿resuelve este problema real mejor que la alternativa establecida? Si la respuesta es sí y el beneficio es suficientemente grande, vale adoptar aunque sea nuevo.
Si el argumento es "es más moderno" o "la comunidad lo está adoptando": eso no es suficiente. Ver criterio técnico antes que framework.
El stack aburrido como ventaja competitiva real
Hay una dimensión de la boring technology que se menciona poco: la velocidad de incorporación. Si tu stack es estándar, cualquier developer puede empezar a trabajar en una semana. Si tu stack es inusual, necesitás tiempo de onboarding específico que no escala.
En la práctica para un founder solo, esto se traduce en capacidad para delegar más eficientemente. Puedo tomar a alguien que conoce Next.js y TypeScript y incorporarlo al proyecto sin explicarle por qué las carpetas están organizadas de una forma no convencional. Puedo pedirle a un agente que haga un cambio y esperar un resultado razonable porque el contexto del stack ya está en su entrenamiento.
Esa ventaja de operación no aparece en los benchmarks de framework comparisons. Pero en un SaaS con un equipo chico, es real y se acumula con el tiempo.
Si estás eligiendo el stack de tu SaaS y querés pensar en cuándo la tecnología aburrida es la decisión correcta, trabajo en proyectos de software bajo solu30.
Preguntas frecuentes
¿Qué es la boring technology y por qué usarla en SaaS? Es tecnología probada, ampliamente adoptada y bien documentada. La apuesta no es ser conservador por miedo: es reservar la complejidad para donde realmente importa.
¿Boring technology significa no actualizar dependencias? No. Significa elegir tecnología con track record comprobado. Podés usar versiones actuales de herramientas estables; la idea es evitar adoptar lo nuevo antes de que sea estable.
¿Los agentes de IA trabajan mejor con tecnología aburrida? Sí. Los agentes trabajan mejor sobre tecnología documentada con muchos ejemplos en su entrenamiento. Una tecnología aburrida tiene millones de ejemplos; una nueva tiene menos contexto disponible.
¿Cuándo sí vale adoptar tecnología nueva? Cuando resuelve un problema real que la tecnología existente no resuelve bien y el beneficio supera el costo de operar algo menos documentado.