De agencia a producto: por qué construimos Pegasuz Core

Hay un punto en el que la repetición deja de ser trabajo y se convierte en diagnóstico. Para nosotros fue cuando el mismo bug apareció en tres proyectos distintos en la misma semana. No era el mismo código copiado — era el mismo error conceptual, cometido tres veces porque no había un lugar común donde habíamos resuelto el problema de verdad.

En ese momento la respuesta correcta no es arreglar el bug tres veces y seguir. Es preguntarse por qué el problema existe tres veces en primer lugar.

La alternativa a seguir copiando era construir algo que no necesitara ser copiado. Un backend que sirviera a múltiples clientes de forma nativa — no como workaround, sino como diseño intencional.

Eso implicaba decisiones que no son triviales. ¿Cómo separás los datos entre clientes sin que un bug exponga información del cliente equivocado? ¿Cómo manejás features distintas por cliente sin llenar el código de condicionales? ¿Cómo actualizás el sistema para todos sin romper las particularidades de cada uno?

Las respuestas que encontramos: base de datos separada por tenant, feature flags por registro, migraciones versionadas y automatizadas. Cada decisión tiene un costo. Cada una también tiene un beneficio que se compound con el tiempo.

El costo de construir el core fue real. Meses de trabajo que no generaban facturación directa. Decisiones de arquitectura que teníamos que tomar sin saber si eran las correctas. Abstracciones que a veces eran demasiado genéricas y a veces demasiado específicas.

Pero el resultado también fue real. Hoy cuando incorporamos un cliente nuevo, el tiempo de setup pasó de semanas a días. Cuando mejoramos el módulo de autenticación, todos los clientes reciben la mejora sin que nadie tenga que hacer nada. Cuando encontramos un bug en el sistema de uploads, lo corregimos una vez.

Más importante: cuando un cliente crece y necesita más funcionalidad, podemos habilitarla. No construirla desde cero.

Cada cliente en Pegasuz corre sobre el mismo backend, con su propia base de datos MySQL. El identificador del cliente viaja en el header HTTP `x-client`. El middleware lo intercepta, resuelve la conexión correcta, y todo lo que viene después trabaja sobre datos aislados.

El panel admin es el mismo para todos. El CMS es el mismo. La autenticación, el sistema de roles, el módulo de publicaciones, los servicios, los proyectos — todo compartido. Lo que varía entre clientes son los datos, las features habilitadas y la personalización visual.

Es la diferencia entre construir proyectos y construir producto. Un proyecto termina. Un producto escala.

En retrospectiva, algunas abstracciones las hicimos demasiado temprano. Generalizamos casos que no se repitieron. Construimos configurabilidad para situaciones que nunca llegaron.

La lección es que la generalización correcta emerge de los casos concretos, no se anticipa. El core que tenemos hoy es el resultado de haber construido cinco clientes reales, no de haber diseñado el sistema perfecto en abstracto.

Eso es lo que significa construir software para uso real: iterar sobre problemas concretos hasta que las soluciones generalizables aparecen solas.