Consultoría de arquitectura de plataformas

Hay un momento en la vida de casi toda plataforma en el que el equipo deja de preguntarse qué construir y empieza a preguntarse qué le frena. Las decisiones se han ido apilando durante años —una cola aquí, un sistema de permisos que creció solo, tres formas distintas de desplegar— y ya nadie tiene el mapa completo. Cada cambio cuesta más que el anterior.

Entonces aparece la tentación: la gran reescritura. Meses de presupuesto para rehacer desde cero lo que hoy funciona, con la esperanza de que esta vez salga bien. A veces es la respuesta correcta. Muchas otras, es la forma más cara de no mirar el problema.

Este servicio existe para ese momento: una revisión experta de las decisiones de arquitectura de tu plataforma, con un plan de evolución priorizado al final.

Qué reviso (y qué no)

No es una auditoría de código. No vengo a pasar un linter caro ni a opinar sobre el estilo de los tests. Me siento con las decisiones grandes —las que cuestan dinero deshacer— y miro si aguantan:

Tenancy: ¿sigue siendo un producto para un cliente o ya es una plataforma para varios? ¿Aislamiento lógico dentro de la aplicación, multi-tenancy por despliegue, o una mezcla de ambos?
Identidad: ¿contraseñas propias o delegada en OIDC con Keycloak? ¿Cómo viajan roles y permisos, y dónde se aplican de verdad?
Colas y workers: qué trabajo corre de forma síncrona, cuál no, y qué pasa cuando algo falla a las tres de la mañana.
Datos: el modelo, las búsquedas, las migraciones que nadie quiere tocar.
Despliegue y operación: qué está versionado, qué se automatiza, cuánto cuesta levantar un entorno nuevo.
IA: dónde aporta de verdad en el producto y dónde es una factura de tokens sin retorno.

El resultado no es un veredicto: es un mapa de decisiones —qué se decidió, con qué contexto, qué consecuencias tiene hoy— y, encima, un plan priorizado: qué mantener, qué revertir, en qué orden y a qué coste. Incluida la opción de no tocar nada cuando es la correcta.

Cómo trabajo

Escuchar antes de leer. Sesiones con dirección técnica, producto y el equipo que opera el sistema. Toda decisión tuvo un contexto; juzgarla sin conocerlo es fácil e inútil.
Leer el sistema real. Repositorios, manifiestos, pipelines, infraestructura. No el diagrama de la presentación: lo que corre de verdad.
Mapear las decisiones. Cada decisión grande queda registrada con su contexto, su estado actual y las opciones que abre o cierra.
Priorizar. El informe ordena los movimientos por impacto y coste, y separa lo urgente de lo que puede esperar —y de lo que no hay que hacer—.

La revisión se discute con el equipo antes de entregarse: un plan que el equipo no compra acaba en un cajón.

De dónde viene el criterio

No hablo de oídas: he tomado estas decisiones con mi nombre y he vivido con sus consecuencias.

En Konect trabajé como arquitecto de software y de plataformas: un producto multi-cliente que se opera como SaaS con RBAC dentro de la aplicación y multi-tenancy por despliegue —cada cliente con su propia configuración, su realm de Keycloak y sus datos aislados—. Kubernetes, GitOps y un entorno de preview por cada pull request.
Zetesis Portal, nuestra propia plataforma, responde distinto a la misma pregunta: multi-tenancy lógico validado en servidor, agentes como datos en el CMS y un núcleo open source de verdad. También es un ejemplo de evolución sin reescritura: la cola migra de Redis Streams a NATS JetStream con la especificación primero y el merge solo cuando aguanta.
El Portal de Antonio Escohotado demuestra lo contrario a «Kubernetes para todo»: búsqueda, agente, paywall y bots corriendo en un único VPS de 6 GB, con Docker Compose bien ordenado. A esa escala era la decisión correcta, y sigue siéndolo.

Tres proyectos, tres respuestas distintas a preguntas parecidas. Eso es lo que aporta una revisión externa: no la receta de moda, sino el criterio de haber visto varias opciones funcionar —y alguna fallar— en sistemas reales.

Cuándo tiene sentido

Estás valorando una reescritura o migración grande y quieres una segunda opinión antes de firmar el presupuesto.
Tu producto pasó de proyecto para un cliente a plataforma para varios y el modelo de tenancy empieza a crujir.
Llevas años con el mismo stack y ya no sabes qué es deuda intencionada y qué es accidente.
Quieres integrar IA en el producto y prefieres saber dónde aporta antes de pagar la factura.

Y cuándo no: si buscas mano de obra para picar código, o alguien que firme un informe sin leer tu sistema, no soy tu consultor.

Hablemos

Si tu plataforma se acerca a una decisión cara —reescritura, migración, salto a SaaS, multi-tenancy—, antes de gastar el dinero podemos mirar juntos qué aguanta y qué no. Reserva una toma de contacto y cuéntame tu caso.