Stack por proyecto, no por dogma: cuatro decisiones de framework en Lemus Digital

La pregunta que no es "¿qué framework es mejor?"

Cada proyecto nuevo trae la misma tentación: abrir con lo que ya conoces bien, o abrir con lo que está de moda esa semana. Ninguna de las dos es una decisión de ingeniería — son atajos para no hacerse la pregunta real. En Lemus Digital operamos, a la vez, un SaaS multi-tenant en producción (Assilek), este mismo sitio y su blog, un negocio pequeño al que le montamos presencia digital (MIA Blue Charters) y una línea completa de implementación de IA (Aiuda Labs) que ni siquiera se apoya en código propio para su capa de automatización. Cuatro contextos, cuatro stacks. Ninguno se eligió por dogma, y tampoco por capricho: cada uno respondió a las mismas cuatro preguntas, con respuestas distintas.

Este post documenta esas preguntas y cómo se respondieron en cada caso — no como un manifiesto de "usa siempre la herramienta correcta" (eso no dice nada operativo), sino con los criterios concretos que de verdad separaron un stack de otro.

Las cuatro preguntas

1. ¿Quién mantiene esto después del primer deploy? Un equipo técnico que va a seguir tocando el código todos los días necesita una cosa; un cliente que no programa necesita otra completamente distinta.
2. ¿Qué tan variable es la carga y el estado? Un producto con usuarios concurrentes, sesiones, tenants y billing necesita capas separadas de responsabilidad. Una página de marketing con tres botones no.
3. ¿Cuál es el costo real de la complejidad, no el costo percibido? Un framework no cuesta lo que cuesta aprenderlo — cuesta lo que cuesta actualizarlo, parchear sus vulnerabilidades y depurar sus capas de abstracción dos años después, con menos memoria fresca del proyecto.
4. ¿Qué pasa si el proyecto crece más de lo esperado? No planificar para eso es un error; sobre-planificarlo desde el día uno también lo es. La pregunta es cuánta holgura comprar por adelantado.

Con esas cuatro preguntas en mente, así se respondieron en cada uno de los cuatro casos.

Caso 1 — Assilek: multi-tenant justifica separar capas

Assilek es un SaaS de galerías fotográficas profesionales: multi-tenant por organización, con marcas de agua configurables, paquetes con límites y precios, procesamiento de imágenes asíncrono y cobro real vía Stripe. El stack productivo es Next.js 14 (App Router) para el front, Spring Boot 3 sobre Java 21 para la API, y un image-service separado —también Spring Boot— que consume una cola de Pub/Sub para procesar imágenes sin bloquear la petición del usuario. Postgres en Cloud SQL, GCS para almacenamiento, todo corriendo en Cloud Run y descrito en Terraform.

Cada pieza de esa lista responde a una de las cuatro preguntas:

• Separar el procesamiento de imágenes del API no es preferencia arquitectónica abstracta — es la respuesta directa a "qué tan variable es la carga". Aplicar una marca de agua en patrón diagonal sobre cientos de fotos de una sesión no puede compartir el mismo proceso que responde en milisegundos a una petición de login o de listado de galerías. Si comparten proceso, un pico de subida de fotos degrada la experiencia de todos los usuarios conectados en ese momento, no solo del que está subiendo.
• Multi-tenancy resuelta por configuración de organización, no por instancias separadas por cliente, responde a "costo real de la complejidad": una instancia por tenant escalaría peor y multiplicaría el trabajo operativo de un equipo de dos personas con empleo de tiempo completo en otro lado.
• Terraform como memoria escrita de la infraestructura responde a "quién mantiene esto": si en seis meses hay que recrear el entorno o entender por qué existe un recurso, el código de infraestructura contesta esa pregunta sin depender de que alguien recuerde haberlo hecho a mano en la consola de GCP.
• Cloud Run en vez de Kubernetes responde a "qué pasa si crece": da margen de escalado horizontal automático sin el costo operativo de administrar un clúster que, para el tráfico actual de Assilek, sería sobre-ingeniería pura.

Ninguna de esas decisiones es exótica — son elecciones convencionales para un SaaS con cobro real y usuarios concurrentes. Lo que las justifica no es que "así se hace un SaaS moderno", sino que Assilek de verdad tiene la variabilidad de carga y la necesidad de aislamiento que ese stack resuelve.

Caso 2 — Este sitio: cero framework es la respuesta correcta, no la ausencia de una

El sitio que estás leyendo (landing + blog) es HTML, CSS y JavaScript inline, sin build step, sin dependencias de npm, servido tal cual desde Firebase Hosting. Comparado con Assilek, eso puede leerse como "no invertimos en esto". Es lo contrario: es la respuesta correcta a las mismas cuatro preguntas, aplicadas a un contexto distinto.

• Carga y estado: una landing y un blog técnico no tienen sesiones de usuario, ni estado que sincronizar entre pestañas, ni concurrencia que gestionar. El único estado real es qué idioma mostrar, y eso se resuelve con una regla de CSS (html[lang="es"] [data-lang="en"] { display: none }) y un script de bootstrap que lee localStorage — no necesita ni React ni un enrutador.
• Costo real de la complejidad: un framework de frontend trae un build step, un package.json con decenas de dependencias transitivas, y actualizaciones que hay que revisar aunque nada del contenido haya cambiado. Para un sitio que no tiene lógica de negocio, ese costo es puro overhead — no compra nada a cambio.
• Quién lo mantiene: este es el punto que de verdad decide el caso. Este mismo blog se alimenta de una rutina programada de Claude Code que escribe un post nuevo cada semana y lo commitea directo a main. Sin build step, ese commit es el artefacto final — no hay una etapa intermedia de compilación que pueda fallar entre "el HTML está bien escrito" y "el HTML está publicado". La validación se reduce a comprobar que el HTML parsea, que el JSON-LD es JSON válido y que el sitemap es XML válido — tres checks deterministas con herramientas estándar de Python, sin necesitar un pipeline de CI con Node, caché de dependencias y un build que puede romperse por una versión de paquete no fijada.
• Qué pasa si crece: si algún día el sitio necesita algo que un framework resuelve mejor (rutas dinámicas, componentes con estado real, un CMS), migrar entonces tiene sentido. Adoptarlo hoy, para contenido que no lo necesita, es pagar el costo de la migración antes de que el problema exista.

Caso 3 — MIA Blue Charters: el cliente decide el criterio, no nosotros

MIA Blue Charters es un negocio de experiencias acuáticas en Miami al que le montamos presencia digital completa: front-end estático a medida, Airtable como CMS headless, una función serverless de por medio para no exponer el token de la API en el navegador, y reservas por WhatsApp. Ninguna pieza de ese stack es la que usaríamos para un SaaS propio — y esa es exactamente la decisión correcta, porque la pregunta "quién lo mantiene" tiene una respuesta distinta cuando el que mantiene el contenido es la dueña del negocio, no un equipo técnico.

La dueña necesita subir un tour nuevo o cambiar un precio desde el celular, sin depender de que alguien le facture por cada cambio. Un CMS de código (Markdown en un repo, un headless CMS con su propio panel de administración que hay que aprender) resuelve ese problema peor que una hoja de cálculo con fotos que ya sabe usar. Airtable no es una limitación técnica aceptada a regañadientes — es la herramienta correcta para quien de verdad va a tocarla todos los días.

Lo que sí se mantuvo constante, independientemente del stack, fue el criterio de ingeniería: separar contenido de código, no exponer secretos en el cliente, dejar un respaldo estático para que la página nunca quede vacía si Airtable no responde. Esos principios no cambian entre proyectos. Las herramientas que los implementan, sí.

Caso 4 — Aiuda Labs: cuando el "framework" es una plataforma, no una librería

Aiuda Labs, la línea de formación e implementación de IA generativa que lidera Noel Moreno Lemus, PhD, desde Panamá, resuelve automatización de flujos comerciales —captación, calificación y conversión de leads en CRMs como GoHighLevel— apoyándose en n8n en vez de construir esa capa de automatización como código propio. Es una decisión que a primera vista contradice la lógica de Assilek: ¿por qué escribir código a medida para un SaaS propio y en cambio delegar en una plataforma low-code para automatización de clientes?

La respuesta vuelve a la primera pregunta: quién mantiene esto. Los clientes de Aiuda Labs son equipos de negocio en LATAM, no equipos de ingeniería. Un flujo de automatización construido en n8n se puede inspeccionar, ajustar y depurar visualmente por alguien que entiende el negocio pero no lee código — eso es exactamente el tipo de mantenimiento que ese cliente puede sostener después de la entrega. Construir la misma automatización como microservicios propios habría sido, para ese contexto, una version más "correcta" técnicamente y mucho peor operativamente: cada ajuste futuro dependería de que Aiuda Labs siguiera involucrada, en vez de dejarle al cliente algo que puede operar solo.

Lo que no cambia entre los cuatro casos

El error más común al hablar de "elegir el stack correcto" es tratarlo como una cuestión de gusto o de moda. No lo es. Las cuatro decisiones de arriba comparten un mismo método, aunque lleguen a herramientas opuestas:

• Nunca se elige el stack antes de tener claro quién lo va a operar después del primer deploy.
• La complejidad se paga con moneda real (tiempo de mantenimiento, superficie de fallo, dependencias que actualizar) — y solo se compra cuando el problema que resuelve ya existe, no cuando podría existir.
• La convención (usar siempre lo mismo) y la novedad (usar siempre lo último) son ambas formas de evitar la pregunta, no de responderla.
• Los principios de ingeniería —separar responsabilidades, no exponer secretos, dejar la infraestructura descrita en código cuando alguien técnico la va a tocar— se mantienen fijos. Las herramientas que los implementan cambian según el contexto.

Cierre

Ningún cliente ni lector necesita saber qué framework usamos — necesita que lo que se construyó para él funcione, sea mantenible por quien tiene que mantenerlo, y no cueste más de lo que el problema justifica. Ese es el único criterio que de verdad importa, y es el mismo en un SaaS con Stripe y billing real que en una página de un negocio de jet skis. El framework es la respuesta a esa pregunta, nunca la pregunta misma.