Sabía lo que las agencias necesitaban—así que construí la arquitectura multi-tenant el Día 2
Después de 20 años en agencias, sabía que la arquitectura multi-tenant no podía esperar—así que el Día 2, con un solo agente de IA funcionando, tripliqué mi complejidad de desarrollo para evitar una reescritura futura.
21 de agosto de 2025. Día 2 de construcción de STRAŦUM.
Estaba sentado en mi escritorio con un agente de IA funcionando (Business Strategy), autenticación básica y un modelo de datos muy simple. El café se estaba enfriando. Sabía exactamente para quién quería construir: PYMEs que necesitaban ayuda con marketing de IA, Y agencias que pudieran usarlo con múltiples clientes.
Ambas audiencias. Desde el Día 1.
Después de 20 años trabajando en el lado de las agencias, entendía lo que las agencias realmente necesitan—no la versión de marketing brillante, sino la realidad desordenada de gestionar 10-15 clientes con estrategias diferentes, directrices de marca diferentes, todo diferente. También sabía que las PYMEs necesitaban desesperadamente ayuda estratégica asequible.
Pero el Día 2, mirando fijamente mi modelo de datos simple, me di cuenta de algo incómodo: construir para ambas audiencias significaba construir arquitectura multi-tenant. Ahora. No después.
Al final del día, me había comprometido con una decisión que triplicaría mi complejidad de desarrollo y extendería mi cronograma por semanas.
Construí arquitectura multi-tenant desde el Día 2.
¿Era esto ambicioso o una locura? Honestamente, no estaba seguro. Todavía no estoy 100% seguro. Pero aquí está la historia de por qué esa decisión—tomada con casi ningún producto funcionando—resultó ser una de las elecciones técnicas más importantes que hice.
¿Por qué ambas audiencias? 20 años de experiencia en agencias
La visión nunca fue solo para PYMEs. Desde el principio, quería construir para dos audiencias distintas:
PYMEs (pequeñas empresas, 1-30 empleados) — El cofundador estratégico que puedes pagar:
- No pueden permitirse agencias de marketing o consultores
- No tienen experiencia en marketing estratégico
- Necesitan victorias rápidas sin curva de aprendizaje
Agencias (gestionando 5-15+ clientes) — Escala tu capacidad estratégica, no tu plantilla:
- Ahogadas en trabajo de estrategia para múltiples clientes
- Necesitan marcos de trabajo consistentes que escalen
- Requieren aislamiento completo de datos entre clientes
¿Por qué agencias? Porque pasé 20 años en el lado de las agencias. Conozco el dolor de primera mano.
He visto estrategas malabareando 12 clientes con 12 directrices de marca diferentes, copiando y pegando contexto entre herramientas, rezando para no enviar accidentalmente la estrategia equivocada al cliente equivocado. He visto agencias perder buenas personas por agotamiento porque no hay manera de escalar el pensamiento estratégico sin escalar la plantilla.
¿Y honestamente? Quería desafiarme. Construir solo para PYMEs sería más sencillo—un usuario, una organización, enrutamiento directo. Construir para agencias significaba dashboards de múltiples clientes, aislamiento de datos, permisos basados en roles, todo con ámbito de cliente.
Quería construir algo complejo. Algo que realmente resolviera los problemas difíciles que había visto durante dos décadas.
La revelación del Día 2: No puedes retrofitar la arquitectura multi-tenant
Esto es lo que entendí el Día 2, mirando fijamente mi modelo de datos simple:
Arquitectura PYME (lo que tenía):
```
users → campaigns → agent_outputs
```
Arquitectura multi-tenant (lo que necesitaba para agencias):
```
organizations (SME or AGENCY)
↓
clients (agencies only)
↓
campaigns
↓
agent_outputs (with org_id AND client_id)
```
La diferencia no es solo "agregar algunas columnas." Es un modelo de datos fundamentalmente diferente.
Si construía para PYMEs primero y agregaba soporte de agencias después, me estaría enfrentando a:
- Migrar cada tabla existente para agregar `org_id`
- Retrofitar políticas RLS en toda la base de datos
- Reescribir el enrutamiento del frontend para el contexto de cliente
- Volver a probar todo con escenarios multi-tenant
Eso no es una adición de funcionalidad. Es una reescritura.
Cuanto más esperara, más caro sería el retrofit. El Día 2 era barato. El Día 60 sería doloroso. El Día 200 sería "quizás simplemente construyamos un producto separado para las agencias."
Así que tomé la decisión: construir multi-tenant desde el Día 2, o aceptar que las agencias nunca serían ciudadanos de primera clase.
Los compromisos: Lo que la arquitectura multi-tenant realmente cuesta
Aquí está la parte en la que debería haberme detenido y preguntarme: "¿Estás seguro de esto? Tienes UN agente funcionando. UNO."
Pero no me detuve. En cambio, empecé a escribir esquemas SQL como un loco. La arquitectura multi-tenant el Día 2 significaba aceptar costos que harían a cualquier persona razonable reconsiderar:
Costo 1: Complejidad de desarrollo (3X)
Cada tabla necesitaba `org_id`. Las tablas de agencias necesitaban `client_id`. Las políticas RLS necesitaban ambos filtros. Cada consulta, cada endpoint de API, cada ruta del frontend—todo tenía que ser consciente de la arquitectura multi-tenant.
Aumento estimado de complejidad: 3X el tiempo de desarrollo para las mismas funcionalidades.
(Spoiler: En realidad fue más cercano a 4X. Lo subestimé. Classic me. :P)
Costo 2: Cronograma de desarrollo extendido
Construir para ambas audiencias desde el Día 1 significaba un camino más largo hasta el lanzamiento. Así es como se veía:
Cronograma:
- 20 de agosto: Empecé a construir (multi-tenant desde el Día 1)
- 15 de septiembre: 4 semanas de trabajo, 3 agentes funcionando, objetivo octubre
- Octubre: Me enfermé 10 días, no pude programar
- 5 de noviembre: Lanzamiento de Alpha Privado (75 días en total)
Lo que agregó la arquitectura multi-tenant:
- Enrutamiento de esquemas entre tablas públicas y de agencias
- Políticas RLS en cada tabla (terminé con 83 en 26 tablas)
- Propagación de contexto de cliente a través de cada agente
- Patrones de enrutamiento duales (URLs de PYME vs. agencia)
¿Habría lanzado más rápido con arquitectura solo para PYMEs? Probablemente 3-4 semanas más rápido. Pero entonces estaría mirando una reescritura cuando las agencias llamaran a la puerta.
Costo 3: Requisitos de seguridad (mayor riesgo)
El aislamiento de datos de PYMEs es lo mínimo esperado. El aislamiento de datos de agencias es crítico para el negocio.
Requisitos agregados:
- 83 políticas RLS en 26 tablas
- Aislamiento a nivel de esquema (esquemas públicos vs. de agencias)
- Funciones de enrutador de base de datos para cada operación CRUD
- Registro de auditoría completo
- Opción de autenticación multifactor
Complejidad de seguridad: 5X mayor que solo para PYMEs.
Algunas semanas gasté más tiempo en políticas de Row-Level Security que en el desarrollo real de agentes de IA. Que eso quede claro.
Costo 4: Complejidad de pruebas (2X casos de prueba)
Cada funcionalidad necesitaba probarse para:
- ✅ Flujo PYME (más simple)
- ✅ Flujo de agencia (con ámbito de cliente)
- ✅ Aislamiento de datos (Nike ≠ Adidas)
- ✅ Límites de permisos (¿pueden las agencias ver datos de PYMEs? No.)
Mantenimiento de pruebas: Duplicado.
¿Sabes qué es divertido? Escribir la misma prueba dos veces con contextos ligeramente diferentes. Eso no lo dijo nadie jamás.
---
Por qué hice el compromiso de todas formas
Déjame entender esto bien: 3X complejidad, cronograma extendido, 5X sobrecarga de seguridad, pruebas duplicadas... ¿y aun así lo hice?
Sí. Aquí está el razonamiento (tal como fue):
Razón 1: El retrofitting es una pesadilla
Día 2: Casi ningún código escrito. Modelo de datos aún flexible. Sin usuarios que migrar.
Día 60: 45 tablas, 200k líneas de código, 15 usuarios alpha. Agregar multi-tenant requeriría reescribir la mitad del codebase.
Lección: Las decisiones arquitectónicas se vuelven exponencialmente más difíciles de cambiar con el tiempo.
Costo el Día 2: ~5 horas para rediseñar el modelo de datos.
Costo el Día 60: ~200 horas para refactorizar todo.
He visto empresas intentar retrofitar la arquitectura multi-tenant. Es brutal. Básicamente estás reconstruyendo el avión mientras vuela. Con pasajeros. Que te están pagando.
Razón 2: Realmente entiendo las agencias
Esto no fue investigación de mercado teórica. Pasé 20 años viendo agencias luchar con exactamente este problema.
Sé que necesitan:
- Aislamiento completo de datos (el cliente 1 no puede ver la estrategia del cliente 2)
- Todo con ámbito de cliente (directrices de marca, personas, campañas)
- Acceso basado en roles (gestores de cuenta vs. estrategas)
- Potencial de marca blanca para presentaciones a clientes
Podía construir esto correctamente porque había vivido el dolor. Esa no es una ventaja que quería desperdiciar enviando solo para PYMEs y "agregando agencias después."
Razón 3: El desafío era el punto
Aquí hay algo que no digo a menudo: *quería* la complejidad.
Soy un fundador de mediana edad con familia, no un chico de 22 años que puede sobrevivir con bebidas energéticas y sin dormir. Si voy a pasar un año construyendo algo, que sea algo que me desafíe. Algo de lo que esté orgulloso técnicamente.
Arquitectura multi-tenant con aislamiento de datos adecuado, políticas RLS, enrutamiento de esquemas—eso es difícil. Es interesante. Es el tipo de problema de ingeniería que me mantiene comprometido a las 2 AM.
Construir solo para PYMEs habría sido más rápido. Pero, ¿habría estado tan motivado para empujar a través de las partes difíciles? Probablemente no.
Razón 4: Ambas audiencias se hacen mejor mutuamente
Las PYMEs y las agencias no son casos de uso en competencia. Son complementarios:
- Las agencias validan el producto: Si las agencias confían en él con datos de clientes, las PYMEs también lo harán
- Las PYMEs proporcionan volumen: Más usuarios significa más feedback, iteración más rápida
- La arquitectura sirve a ambos: Las cuentas de equipo, los permisos de roles y la marca blanca funcionan para ambas audiencias
Construir para ambos significaba construir la solución *completa*, no una versión simplificada de la que me quedaría pequeño.
Razón 5: Prepararse para el futuro
Incluso más allá de las agencias, la arquitectura multi-tenant habilitó:
- Cuentas de equipo (PYMEs con múltiples usuarios)
- Asociaciones de revendedores
- Oportunidades de marca blanca
- Ventas empresariales (si alguna vez quisiéramos ir por ahí)
Valor de opción: La arquitectura multi-tenant desbloqueó modelos de negocio que ni siquiera podía imaginar el Día 2.
La implementación: Qué aspecto tuvieron las decisiones de arquitectura del Día 2
Esto es lo que realmente construí el 21 de agosto:
Esquema de base de datos (Decisión central)
```sql
-- Organizations table (SME or AGENCY)
CREATE TABLE organizations (
id UUID PRIMARY KEY,
name TEXT,
type TEXT CHECK (type IN ('SME', 'AGENCY')), -- Critical distinction
created_at TIMESTAMPTZ DEFAULT NOW()
);
-- Clients table (agencies only)
CREATE TABLE clients (
id UUID PRIMARY KEY,
org_id UUID REFERENCES organizations(id), -- Which agency owns this
company_name TEXT,
slug TEXT UNIQUE, -- For URL routing
created_at TIMESTAMPTZ DEFAULT NOW(),
-- Constraint: Only agencies can have clients
CONSTRAINT clients_agency_only CHECK (
(SELECT type FROM organizations WHERE id = org_id) = 'AGENCY'
)
);
-- Campaigns table (multi-tenant aware)
CREATE TABLE campaigns (
id UUID PRIMARY KEY,
org_id UUID REFERENCES organizations(id), -- Always required
client_id UUID REFERENCES clients(id), -- Required for agencies, null for SMEs
name TEXT,
created_at TIMESTAMPTZ DEFAULT NOW()
);
-- Agent outputs (multi-tenant + client-scoped)
CREATE TABLE agent_outputs (
id UUID PRIMARY KEY,
org_id UUID REFERENCES organizations(id),
client_id UUID REFERENCES clients(id),
campaign_id UUID REFERENCES campaigns(id),
agent_type TEXT,
content JSONB,
created_at TIMESTAMPTZ DEFAULT NOW()
);
```
Decisiones clave el Día 2:
- `org_id` en cada tabla (habilita RLS)
- `client_id` anulable (las PYMEs no tienen clientes)
- Discriminador `type` en organizaciones (PYME vs. AGENCIA)
- Restricción: Solo las agencias pueden crear clientes
Row-Level Security (planificación del Día 2)
```sql
-- RLS policy for campaigns (multi-tenant isolation)
CREATE POLICY campaigns_org_isolation ON campaigns
FOR ALL TO authenticated
USING (
org_id = get_user_org_id() AND
(client_id IS NULL OR client_id IN (SELECT id FROM clients WHERE org_id = get_user_org_id()))
);
```
Esta política garantiza:
- ✅ Los usuarios solo ven campañas de su organización
- ✅ Los usuarios de agencias no pueden ver campañas de PYMEs
- ✅ Las agencias no pueden ver los clientes de las demás
Costo: Escribí 5 políticas RLS iniciales el Día 2. Eventualmente creció hasta 83 para el lanzamiento.
Enrutamiento de URL (Multi-tenant desde el Día 1)
```typescript
// Frontend routing structure (planned Day 2)
// SME routes (simple)
/campaigns/:campaignId
/agents/strategy/:campaignId
// Agency routes (client-scoped)
/clients/:clientSlug/campaigns/:campaignId
/clients/:clientSlug/agents/strategy/:campaignId
```
Esta estructura de URL habilitó:
- ✅ Contexto de cliente en cada URL (agencias)
- ✅ Separación clara entre flujos de PYME y Agencia
- ✅ URLs guardables y compartibles
- ✅ Seguimiento de analíticas por cliente
Los resultados: ¿Valió la pena?
Fecha de lanzamiento: 5 de noviembre de 2025 (75 días desde el inicio)
Sobrecarga de desarrollo por la arquitectura multi-tenant:
- Diseño de esquema y migraciones
- 83 políticas RLS en 26 tablas
- Funciones de enrutador de base de datos
- Patrones de enrutamiento duales (URLs de PYME vs. agencia)
- Propagación de contexto de cliente
Con Claude Code y Gemini 2.5 Pro, la codificación real fue más rápida de lo que habría sido en solitario. ¿Pero depurar políticas RLS que *deberían* funcionar pero no funcionan? Eso sigue siendo doloroso a las 2 AM independientemente de la asistencia de IA.
Lo que tengo ahora:
- Aislamiento completo de datos entre organizaciones
- Arquitectura lista para agencias con ámbito de cliente
- 83 políticas RLS en 26 tablas
- Enrutamiento a nivel de esquema (esquemas públicos vs. de agencias)
- Potencial de marca blanca incorporado desde el Día 1
- Un producto que genuinamente puede servir tanto a PYMEs como a agencias
¿Valió la pena?
Pregúntame en 6 meses cuando tenga clientes reales pagando dinero real. Ahora mismo estoy en alpha privado con 15+ usuarios, todavía aprendiendo qué funciona y qué no.
Pero esto es lo que sé: tengo la arquitectura para servir a ambas audiencias adecuadamente. Si hubiera construido solo para PYMEs e intentado agregar agencias después, estaría mirando una reescritura de 3 meses ahora mismo. En cambio, estoy enfocado en el product-market fit, no en la deuda arquitectónica.
Eso se siente como el compromiso correcto.
El marco: Cuándo construir arquitectura multi-tenant temprano
No todos los productos necesitan arquitectura multi-tenant el Día 2. Usa este marco:
Construye arquitectura multi-tenant temprano si:
✅ El mercado objetivo incluye agencias/revendedores (mayor valor por cliente)
✅ El aislamiento de datos es crítico (requisitos legales/de cumplimiento)
✅ B2B con cuentas de equipo probables (modelo Slack, Figma)
✅ Existen oportunidades de marca blanca (estrategia GTM de revendedor)
✅ Las ventas empresariales son posibles (necesidad de multi-cliente desde el Día 1)
Omite la arquitectura multi-tenant temprano si:
❌ Producto B2C (usuarios individuales, sin jerarquía organizacional)
❌ El MVP necesita velocidad (prueba el product-market fit primero)
❌ Sin caso de uso de equipo/agencia (herramientas de un solo jugador)
❌ Modelo de datos simple (agregar org_id después es fácil)
❌ Fundadores en solitario aprendiendo (la complejidad puede ser demasiado)
Lecciones aprendidas: Construye para tu experiencia
1. El conocimiento de la audiencia debe impulsar la arquitectura
No diseñes para usuarios hipotéticos. Diseña para usuarios que realmente entiendes.
Mi ventaja: 20 años de experiencia en agencias significaban que sabía exactamente lo que las agencias necesitaban—aislamiento de datos, ámbito de cliente, acceso basado en roles.
Enfoque incorrecto: "Construyamos para PYMEs primero y agreguemos agencias después cuando las entendamos"
Enfoque correcto: "Ya entiendo las agencias. Construir para ellas ahora mientras es barato."
Si tienes experiencia profunda en un segmento de mercado, úsala. No lo diferyas a "más simple primero."
2. La complejidad temprana vence a la refactorización tardía
Costo de arquitectura el Día 2: 5 horas para rediseñar el modelo de datos.
Costo de arquitectura el Día 60: 200 horas para refactorizar todo.
Diferencia de 40X.
Si estás 80% seguro de que necesitarás arquitectura multi-tenant, constrúyela temprano. Cuanto más esperes, más caro se vuelve.
3. El desafío técnico puede ser motivación
Esta es personal: *quería* construir algo difícil.
Arquitectura multi-tenant con políticas RLS, enrutamiento de esquemas y aislamiento de datos adecuado—eso es ingeniería interesante. Me mantuvo comprometido durante las partes difíciles.
Si eres un fundador en solitario, no subestimes la motivación. Construir algo que te desafíe puede valer más que enviar más rápido.
4. La arquitectura habilita modelos de negocio
La arquitectura multi-tenant no fue solo una decisión técnica. Habilitó:
- Niveles de precios para agencias (cuando finalmente descifre los precios)
- Oportunidades de marca blanca
- Potencial de ventas empresariales
- Cuentas de equipo para PYMEs
Arquitectura = opcionalidad de negocio en forma de código.
5. Los fundadores en solitario pueden construir arquitectura multi-tenant
"La arquitectura multi-tenant es demasiado compleja para una persona" → Falso.
Con las herramientas modernas (Supabase RLS, funciones de base de datos, desarrollo asistido por IA), los fundadores en solitario pueden construir arquitectura multi-tenant de calidad empresarial.
Costo de tiempo: 70 días (a tiempo parcial).
Lo que obtienes: Aislamiento de datos real, no un hack del que te arrepentirás después.
Vale la pena si eres serio sobre servir a ambas audiencias
Reflexiones finales
El Día 2 era demasiado pronto para saber si STRAŦUM tendría éxito. Tenía un agente. Sin usuarios. Sin validación. Solo 20 años de experiencia en agencias diciéndome lo que las agencias realmente necesitan.
El cronograma extendido se sintió doloroso a veces. ¿Ver otros lanzamientos mientras todavía estaba depurando políticas RLS y escribiendo funciones de enrutador de base de datos? Frustrante se queda corto. Hubo días en que me pregunté si la complejidad valía la pena.
Pero esto es lo que sé ahora: construir para ambas audiencias desde el Día 1 fue la decisión correcta. No por algún cálculo astuto de economía unitaria—todavía no sé qué precios funcionarán. Sino porque tengo la arquitectura para servir a ambas audiencias adecuadamente.
La arquitectura multi-tenant el Día 2 no fue solo una decisión técnica. Fue una apuesta por construir para usuarios que realmente entiendo, no usuarios hipotéticos que descifraría más tarde.
¿Esa apuesta dio sus frutos?
Todavía estoy en Alpha Privado con 15+ usuarios. Todavía no tengo la respuesta. Pero puedo decirte esto: cuando una agencia se acerca y pregunta "¿podemos usar esto para múltiples clientes con aislamiento de datos adecuado?" puedo decir que sí. No tengo que decir "estamos trabajando en eso."
Eso se siente como la base correcta.
El tiempo dirá si fui ambicioso o simplemente terco. (Probablemente un poco de ambos, honestamente.) :)
¿Alguna vez hiciste una apuesta de arquitectura temprano que se sintió demasiado ambiciosa en ese momento — y dio sus frutos? Me encantaría escuchar tu historia.
Un abrazo,
Chandler
La serie de arquitectura de STRAŦUM: Esta decisión del Día 2 fue solo el comienzo. El Día 67, tuve que reconstruir toda la capa multi-tenant cuando una auditoría de seguridad reveló fallas arquitectónicas. Luego llegaron 31 pantallas en blanco por contexto de navegación perdido, y el descubrimiento de que mi base de datos era técnicamente correcta pero 296 veces demasiado lenta.
---
¿Construyendo un SaaS multi-tenant? La arquitectura de STRAŦUM soporta tanto clientes PYME como de Agencia desde el Día 1. Solicita acceso alpha en https://stratum.chandlernguyen.com/request-invitation
---
Todavía aprendiendo que las decisiones de arquitectura son decisiones de negocio disfrazadas. Todavía depurando políticas RLS. Todavía cuestionando mis decisiones del Día 2 (pero menos que antes). Más aventuras de construcción en https://www.chandlernguyen.com/.
---
