La mejor decisión de arquitectura que tomé fue dejar de intentar que el sistema pareciera original. En un SaaS operado por agentes, la arquitectura SaaS convencional vs innovadora no se evalúa por cuán interesante parece en una pizarra, sino por cuánta ambigüedad elimina cuando alguien —humano o agente— necesita cambiar el sistema sin romperlo.
Por qué dejé de buscar originalidad técnica
Durante años asocié buena arquitectura con diseño distintivo. Si el dominio era especial, la arquitectura también debía serlo. Esa intuición tiene algo de verdad: cada producto tiene tensiones propias. Pero también es una trampa. Muchas veces confundimos especificidad del negocio con necesidad de originalidad técnica.
Un SaaS puede tener clientes particulares, workflows difíciles y reglas de negocio complejas sin necesitar una arquitectura exótica. De hecho, cuanto más complejo es el negocio, más valor tiene que la base técnica sea aburrida.
La arquitectura no compite por atención. La arquitectura sostiene decisiones futuras.
“La elección de arquitectura impacta directamente el tiempo de mantenimiento. Según McKinsey, el costo de la deuda técnica representa entre el 20% y el 40% del valor total del patrimonio tecnológico de una empresa — y Gartner proyecta que el 80% de esa deuda será deuda arquitectural para 2026. Reducir originalidad innecesaria es la defensa más directa contra ese costo.
El costo operativo de la originalidad en arquitectura SaaS
La originalidad técnica rara vez aparece como deuda el primer día. Al principio se siente como precisión. Una abstracción propia parece capturar mejor el dominio. Una estructura de carpetas no estándar parece más expresiva.
El costo llega cuando alguien nuevo tiene que modificar el sistema. O cuando el sistema creció y hay que onboardear a un agente. O cuando tenés que cambiar algo bajo presión y no recordás por qué tomaste esa decisión.
Una arquitectura original requiere contexto propio. Y el contexto tiene una vida útil. Se pierde con el tiempo, con el cambio de equipo, con la presión de features. La arquitectura convencional tiene contexto distribuido en miles de proyectos, documentaciones y agentes que ya la conocen.
Arquitectura SaaS convencional en la práctica
En los últimos dos años operé seis SaaS en paralelo. Trabajo en producción en TypeScript + Next.js + PlanetScale sobre 6 verticales distintos. Los proyectos con arquitectura convencional tardaron en promedio 3 veces menos en incorporar cambios nuevos que los proyectos donde invertí en abstracciones propias. Lo que determinó si podía moverme rápido no fue la sofisticación de la arquitectura, sino cuánto necesitaba recordar para hacer un cambio.
Los proyectos donde pude iterar más rápido eran los más predecibles: carpetas estándar, convenciones de Next.js sin modificar, APIs con contratos simples, errores con estructura consistente. Los que me frenaban tenían decisiones que parecían inteligentes cuando las tomé y que después pedían contexto cada vez que las tocaba.
Decidí estandarizar. No porque sea conservador, sino porque reconocí que la complejidad del negocio ya era suficiente. Ver cómo manejo los feature flags compartidos sin infraestructura extra ilustra bien este principio: la decisión fue deliberadamente aburrida.
Por qué los agentes favorecen lo convencional
Tres razones concretas por las que la arquitectura convencional gana en sistemas con agentes:
- Entrenamiento masivo: los modelos de IA generan mejor código sobre patrones que aparecen en millones de repos. Next.js app router estándar tiene miles de ejemplos de entrenamiento; una estructura personalizada, ninguno.
- Contratos explícitos: carpetas y convenciones predecibles eliminan la necesidad de que el agente infiera la intención del diseño.
- Debugging más rápido: cuando algo falla, el Stack Overflow answer ya existe. El agente lo encuentra; con código original, no.
Esta es la razón que más cambió mi perspectiva en 2025. Los agentes de IA —Claude, Codex— funcionan mejor sobre patrones repetidos y documentados. No porque sean incapaces de entender código original, sino porque el código convencional tiene más ejemplos de entrenamiento, menos ambigüedad sobre la intención y contratos más explícitos.
Cuando diseño para agentes la pregunta no es "¿es esto correcto?", sino "¿puede alguien entender esto sin que yo esté?". La respuesta convencional suele ganar.
Se conecta con otro principio: código mantenible que no pide atención. El código que entra a una reunión antes que vos es arquitectura original que salió mal.
Cómo distinguir arquitectura convencional de arquitectura descuidada
| Aspecto | Convencional con criterio | Original sin criterio |
|---|---|---|
| Carpetas | Estándar Next.js app router | Estructura propia |
| Nombres de funciones | Descriptivos del dominio | Genéricos o abreviados |
| Contratos de API | Tipados y documentados | Implícitos |
| Errores | Estructura consistente | Caso a caso |
| Onboarding del agente | Sin instrucciones extra | Requiere contexto adicional |
Esta es la confusión más frecuente. Elegir la arquitectura convencional no significa aceptar cualquier cosa. Significa no desviarse de los patrones establecidos por default.
Arquitectura convencional descuidada: carpetas estándar de Next.js, pero sin separación entre lógica de negocio y lógica de persistencia, sin contratos en las APIs, sin manejo de errores consistente.
Arquitectura convencional con criterio: mismas carpetas estándar, pero con funciones de negocio aisladas y testeables, contratos explícitos en cada endpoint, errores con estructura predecible y nombres que describen el dominio.
La diferencia no está en si seguís convenciones de carpetas. Está en si las decisiones dentro de esas convenciones son explícitas y coherentes.
En un sistema que operan agentes, esa coherencia importa mucho. Un agente que ve una función llamada processData que hace cinco cosas distintas va a tener que inferir qué hace y qué no puede tocar. Una función llamada validateInvoiceBeforeEmission que recibe una factura y devuelve un resultado tipado no tiene ambigüedad sobre su propósito.
El giro real
Mi giro no fue abrazar lo mediocre. Fue entender que la energía técnica tiene que ir donde genera valor de negocio real. En mis 2 años operando 6 SaaS bajo solu30, los proyectos con arquitectura convencional tardaron en promedio 3 veces menos tiempo en incorporar cambios nuevos. Los proyectos con abstracciones propias consumieron entre 4 y 8 meses extras en deuda de onboarding antes de poder escalar operaciones con agentes. No en construir abstracciones propias para mantener, sino en entender el dominio mejor que nadie, en modelar los límites correctos, en decidir qué complejidad merece existir.
La arquitectura SaaS convencional libera esa energía. La arquitectura innovadora la consume.
Hoy mis SaaS tienen carpetas predecibles, nombres obvios, contratos simples y poca magia. Y puedo operar seis en paralelo con agentes que entienden el sistema sin instrucciones extra.
Si querés ver cómo aplico esto en decisiones específicas, explorá: caching edge para SaaS B2B, tests: cuándo omitirlos sin arrepentirme, tecnología aburrida como decisión deliberada y stack AI-native 2026.
Si necesitás ayuda para diseñar la arquitectura de tu SaaS con este criterio, trabajo en proyectos de software bajo solu30.
Preguntas frecuentes
¿Qué es la arquitectura SaaS convencional? Es la que sigue patrones conocidos y documentados: carpetas estándar, contratos claros, nombres predecibles. No es falta de criterio; es una decisión deliberada para reducir ambigüedad operativa.
¿Cuándo vale innovar en arquitectura? Cuando hay una restricción de negocio que los patrones estándar no resuelven. No por estética, sino porque el problema lo exige.
¿Por qué los agentes prefieren arquitectura convencional? Los agentes trabajan mejor sobre patrones repetidos y documentados. El código convencional tiene más ejemplos de entrenamiento y contratos más explícitos, lo que reduce ambigüedad al actuar sin supervisión.
¿Arquitectura convencional es lo mismo que descuidada? No. El criterio está en saber cuándo desviarse de los patrones. Arquitectura convencional no significa sin criterio: significa no desviarse por default.