Eu Sabia o Que as Agências Precisavam — Então Construí Multi-Tenancy no Dia 2

21 de agosto de 2025. Dia 2 de construção do STRAŦUM.

Eu estava sentado na minha mesa com um agente de IA funcionando (Estratégia de Negócios), autenticação básica e um modelo de dados muito simples. O café esfriando. Eu sabia exatamente para quem queria construir: PMEs que precisavam de ajuda de marketing com IA, E agências que poderiam usá-lo com múltiplos clientes.

Ambos os públicos. Desde o Dia 1.

Depois de 20 anos trabalhando no lado da agência, entendi o que as agências realmente precisam — não a versão brilhante do marketing, mas a realidade bagunçada de gerenciar 10-15 clientes com estratégias diferentes, diretrizes de marca diferentes, tudo diferente. Também sabia que as PMEs precisavam desesperadamente de ajuda estratégica acessível.

Mas no Dia 2, olhando para meu modelo de dados simples, percebi algo desconfortável: construir para ambos os públicos significava construir arquitetura multi-tenant. Agora. Não depois.

Até o final do dia, eu tinha me comprometido com uma decisão que triplicaria minha complexidade de desenvolvimento e estenderia meu cronograma por semanas.

Construí arquitetura multi-tenant desde o Dia 2.

Isso foi ambicioso ou insano? Honestamente, não tinha certeza. Ainda não tenho 100% de certeza. Mas aqui está a história de por que essa decisão — tomada com quase nenhum produto funcionando — acabou sendo uma das escolhas técnicas mais importantes que fiz.

Por Que Dois Públicos? 20 Anos de Experiência em Agências

A visão nunca foi só para PMEs. Desde o início, queria construir para dois públicos distintos:

PMEs (Pequenas empresas, 1-30 funcionários) — O Co-Fundador Estratégico Que Você Pode Pagar:

- Não podem pagar agências de marketing ou consultores

- Não têm expertise de marketing estratégico

- Precisam de vitórias rápidas sem a curva de aprendizado

Agências (Gerenciando 5-15+ clientes) — Escale Sua Capacidade Estratégica, Não Seu Quadro:

- Afogando em trabalho de estratégia com múltiplos clientes

- Precisam de frameworks consistentes que escalem

- Exigem isolamento completo de dados entre clientes

Por que agências? Porque passei 20 anos no lado da agência. Conheço a dor em primeira mão.

Já vi estrategistas equilibrar 12 clientes com 12 diretrizes de marca diferentes, copiando e colando contexto entre ferramentas, rezando para não enviar acidentalmente a estratégia errada para o cliente errado. Já vi agências perder boas pessoas para o esgotamento porque não há como escalar o pensamento estratégico sem escalar o quadro de funcionários.

E honestamente? Queria me desafiar. Construir apenas para PMEs seria mais simples — um usuário, uma organização, roteamento direto. Construir para agências significava dashboards multi-clientes, isolamento de dados, permissões baseadas em funções, tudo com escopo de cliente.

Queria construir algo complexo. Algo que realmente resolvesse os problemas difíceis que via há duas décadas.

A Percepção do Dia 2: Você Não Pode Retrofitar Multi-Tenancy

Aqui está o que entendi no Dia 2, olhando para meu modelo de dados simples:

Arquitetura de PME (o que eu tinha):

```
users → campaigns → agent_outputs
```

Arquitetura multi-tenant (o que precisava para agências):

```
organizations (PME ou AGÊNCIA)
  ↓
clients (apenas agências)
  ↓
campaigns
  ↓
agent_outputs (com org_id E client_id)
```

A diferença não é só "adicionar algumas colunas." É um modelo de dados fundamentalmente diferente.

Se eu construísse para PMEs primeiro e adicionasse suporte a agências depois, estaria olhando para:

- Migrar cada tabela existente para adicionar org_id

- Retrofistar políticas RLS em todo o banco de dados

- Reescrever o roteamento do frontend para contexto de cliente

- Re-testar tudo com cenários multi-tenant

Isso não é uma adição de funcionalidade. É uma reescrita.

Quanto mais eu esperasse, mais cara seria a retrofitagem. O Dia 2 era barato. O Dia 60 seria doloroso. O Dia 200 seria "talvez a gente construa um produto separado para agências."

Então tomei a decisão: construir multi-tenant desde o Dia 2, ou aceitar que as agências nunca seriam cidadãos de primeira classe.

As Trocas: O Que Multi-Tenancy Realmente Custa

Aqui está a parte onde eu deveria ter pausado e me perguntado: "Tem certeza disso? Você tem UM agente funcionando. UM."

Mas não pausei. Em vez disso, comecei a escrever schemas SQL como um louco. Multi-tenancy no Dia 2 significava aceitar custos que fariam qualquer pessoa razoável reconsiderar:

Custo 1: Complexidade de Desenvolvimento (3X)

Cada tabela precisava de org_id. As tabelas de agências precisavam de client_id. As políticas RLS precisavam de ambos os filtros. Cada query, cada endpoint de API, cada rota de frontend — todos tinham que ser multi-tenant aware.

Aumento estimado de complexidade: 3X de tempo de desenvolvimento para as mesmas funcionalidades.

(Spoiler: Na verdade foi mais perto de 4X. Subestimei. Clássico meu. :P)

Custo 2: Cronograma de Desenvolvimento Estendido

Construir para ambos os públicos desde o Dia 1 significava um caminho mais longo até o lançamento. Veja como foi:

Cronograma:

- 20 de agosto: Comecei a construir (multi-tenant desde o Dia 1)

- 15 de setembro: 4 semanas depois, 3 agentes funcionando, mirando outubro

- Outubro: Fiquei doente por 10 dias, não conseguia codar

- 5 de novembro: Lançamento do Alpha Privado (75 dias no total)

O que multi-tenancy adicionou:

- Roteamento de schema entre tabelas públicas e de agências

- Políticas RLS em cada tabela (acabei com 83 em 26 tabelas)

- Propagação de contexto de cliente por cada agente

- Padrões de roteamento dual (URLs de PME vs. agência)

Eu teria lançado mais rápido com arquitetura apenas para PMEs? Provavelmente 3-4 semanas mais rápido. Mas então estaria olhando para uma reescrita quando as agências viessem bater.

Custo 3: Requisitos de Segurança (Risco Mais Alto)

Isolamento de dados de PME é mínimo. Isolamento de dados de agência é missão crítica.

Requisitos adicionados:

- 83 políticas RLS em 26 tabelas

- Isolamento em nível de schema (schemas públicos vs. de agência)

- Funções de roteador de banco de dados para cada operação CRUD

- Log de auditoria abrangente

- Opção de autenticação multifator

Complexidade de segurança: 5X maior que apenas PME.

Passei mais tempo em políticas de Row-Level Security do que em desenvolvimento de agente de IA em algumas semanas. Deixa isso assentar.

Custo 4: Complexidade de Testes (2X Casos de Teste)

Cada funcionalidade precisou de testes para:

- ✅ Fluxo de PME (mais simples)

- ✅ Fluxo de agência (com escopo de cliente)

- ✅ Isolamento de dados (Nike ≠ Adidas)

- ✅ Limites de permissão (as agências podem ver dados de PME? Não.)

Manutenção de testes: Dobrou.

Sabe o que é divertido? Escrever o mesmo teste duas vezes com contextos ligeiramente diferentes. Disse ninguém jamais.

---

Por Que Fiz a Troca Mesmo Assim

Então me digam: 3X de complexidade, cronograma estendido, 5X de overhead de segurança, testes dobrados... e ainda assim fiz?

É. Aqui está o raciocínio (ou o que havia dele):

Razão 1: Retrofitagem é um Pesadelo

Dia 2: Quase nenhum código escrito. Modelo de dados ainda flexível. Sem usuários para migrar.

Dia 60: 45 tabelas, 200k linhas de código, 15 usuários alpha. Adicionar multi-tenancy exigiria reescrever metade da base de código.

Lição: Decisões arquiteturais ficam exponencialmente mais difíceis de mudar com o tempo.

Custo no Dia 2: ~5 horas para redesenhar o modelo de dados.

Custo no Dia 60: ~200 horas para refatorar tudo.

Já vi empresas tentando retrofistar multi-tenancy. É brutal. Você está basicamente reconstruindo o avião enquanto voa. Com passageiros. Que estão te pagando.

Razão 2: Eu Realmente Entendo Agências

Não foi pesquisa de mercado teórica. Passei 20 anos vendo agências lutarem exatamente com esse problema.

Sei que precisam de:

- Isolamento completo de dados (o cliente 1 não pode ver a estratégia do cliente 2)

- Tudo com escopo de cliente (diretrizes de marca, personas, campanhas)

- Acesso baseado em funções (gerentes de conta vs. estrategistas)

- Potencial white-label para apresentações a clientes

Pude construir isso direito porque vivi a dor. Essa não é uma vantagem que queria desperdiçar construindo apenas para PMEs e "adicionando agências depois."

Razão 3: O Desafio Era o Ponto

Aqui está algo que não digo com frequência: eu *queria* a complexidade.

Sou um fundador de meia-idade com família, não um jovem de 22 anos que sobrevive a bebidas energéticas e sem dormir. Se vou passar um ano construindo algo, é melhor ser algo que me desafie. Algo do qual me orgulhe tecnicamente.

Arquitetura multi-tenant com políticas de isolamento de dados adequadas, políticas RLS, roteamento de schema — isso é difícil. É interessante. É o tipo de problema de engenharia que me mantém engajado às 2 da manhã.

Construir apenas para PMEs teria sido mais rápido. Mas eu teria sido tão motivado para superar as partes difíceis? Provavelmente não.

Razão 4: Ambos os Públicos Se Tornam Melhores Um Pelo Outro

PMEs e agências não são casos de uso concorrentes. São complementares:

- As agências validam o produto: Se as agências confiam nele com dados de clientes, as PMEs também confiarão

- As PMEs fornecem volume: Mais usuários significa mais feedback, iteração mais rápida

- A arquitetura serve a ambos: Contas de equipe, permissões de função e white-label funcionam para ambos os públicos

Construir para ambos significava construir a solução *completa*, não uma versão simplificada da qual eu me arrependeria.

Razão 5: Preparação para o Futuro

Além das agências, a arquitetura multi-tenant habilitou:

- Contas de equipe (PMEs com múltiplos usuários)

- Parcerias de revendedor

- Oportunidades de white-label

- Vendas enterprise (se quiséssemos ir por esse caminho)

Valor de opção: Multi-tenancy desbloqueou modelos de negócios que eu nem conseguia imaginar no Dia 2.

A Implementação: Como Foram as Decisões de Arquitetura do Dia 2

Aqui está o que realmente construí em 21 de agosto:

Schema de Banco de Dados (Decisão Central)

```sql
-- Tabela de organizações (PME ou AGÊNCIA)
CREATE TABLE organizations (
  id UUID PRIMARY KEY,
  name TEXT,
  type TEXT CHECK (type IN ('SME', 'AGENCY')),  -- Distinção crítica
  created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Tabela de clientes (apenas agências)
CREATE TABLE clients (
  id UUID PRIMARY KEY,
  org_id UUID REFERENCES organizations(id),  -- Qual agência possui isso
  company_name TEXT,
  slug TEXT UNIQUE,  -- Para roteamento de URL
  created_at TIMESTAMPTZ DEFAULT NOW(),

  -- Restrição: Apenas agências podem ter clientes
  CONSTRAINT clients_agency_only CHECK (
    (SELECT type FROM organizations WHERE id = org_id) = 'AGENCY'
  )
);

-- Tabela de campanhas (multi-tenant aware)
CREATE TABLE campaigns (
  id UUID PRIMARY KEY,
  org_id UUID REFERENCES organizations(id),  -- Sempre obrigatório
  client_id UUID REFERENCES clients(id),      -- Obrigatório para agências, null para PMEs
  name TEXT,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Outputs dos agentes (multi-tenant + com escopo de cliente)
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()
);
```

Decisões-chave no Dia 2:

- org_id em cada tabela (habilita RLS)

- client_id nullable (PMEs não têm clientes)

- Discriminador type em organizações (PME vs. AGÊNCIA)

- Restrição: Apenas agências podem criar clientes

Row-Level Security (Planejamento do Dia 2)

```sql
-- Política RLS para campanhas (isolamento multi-tenant)
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()))
  );
```

Essa política garante:

- ✅ Usuários veem apenas campanhas de sua organização

- ✅ Usuários de agências não podem ver campanhas de PMEs

- ✅ Agências não podem ver os clientes umas das outras

Custo: Escrevi 5 políticas RLS iniciais no Dia 2. Cresceu para 83 até o lançamento.

Roteamento de URL (Multi-Tenant desde o Dia 1)

```typescript
// Estrutura de roteamento do frontend (planejada no Dia 2)

// Rotas de PME (simples)
/campaigns/:campaignId
/agents/strategy/:campaignId

// Rotas de agência (com escopo de cliente)
/clients/:clientSlug/campaigns/:campaignId
/clients/:clientSlug/agents/strategy/:campaignId
```

Essa estrutura de URL habilitou:

- ✅ Contexto de cliente em cada URL (agências)

- ✅ Separação clara entre fluxos de PME e Agência

- ✅ URLs marcáveis e compartilháveis

- ✅ Rastreamento de analytics por cliente

Os Resultados: Valeu a Pena?

Data de lançamento: 5 de novembro de 2025 (75 dias desde o início)

Overhead de desenvolvimento por multi-tenancy:

- Design de schema e migrações

- 83 políticas RLS em 26 tabelas

- Funções de roteador de banco de dados

- Padrões de roteamento dual (URLs de PME vs. agência)

- Propagação de contexto de cliente

Com o Claude Code e o Gemini 2.5 Pro, a codificação real foi mais rápida do que seria sozinho. Mas depurar políticas RLS que *deveriam* funcionar mas não funcionam? Ainda é doloroso às 2 da manhã independente da assistência de IA.

O que tenho agora:

- Isolamento completo de dados entre organizações

- Arquitetura pronta para agências com escopo de cliente

- 83 políticas RLS em 26 tabelas

- Roteamento em nível de schema (schemas públicos vs. de agência)

- Potencial white-label incorporado desde o Dia 1

- Um produto que pode genuinamente servir a ambos os públicos

Valeu a pena?

Pergunte-me daqui a 6 meses quando tiver clientes reais pagando dinheiro real. Agora estou em alpha privado com 15+ usuários, ainda aprendendo o que funciona e o que não funciona.

Mas aqui está o que sei: tenho a arquitetura para servir adequadamente a ambos os públicos. Se tivesse construído apenas para PMEs e tentado adicionar agências depois, estaria olhando para uma reescrita de 3 meses agora. Em vez disso, estou focado em product-market fit, não em dívida arquitetural.

Parece ser a troca certa.

O Framework: Quando Construir Multi-Tenancy Cedo

Nem todo produto precisa de multi-tenancy no Dia 2. Use este framework:

Construa Multi-Tenancy Cedo Se:

✅ Mercado-alvo inclui agências/revendedores (maior valor por cliente)

✅ Isolamento de dados é crítico (requisitos legais/de conformidade)

✅ B2B com contas de equipe prováveis (modelo Slack, Figma)

✅ Oportunidades de white-label existem (estratégia GTM de revendedor)

✅ Vendas enterprise é possível (necessita multi-cliente desde o Dia 1)

Pule Multi-Tenancy Cedo Se:

❌ Produto B2C (usuários individuais, sem hierarquia organizacional)

❌ MVP precisa de velocidade (teste product-market fit primeiro)

❌ Sem caso de uso de equipe/agência (ferramentas single-player)

❌ Modelo de dados simples (adicionar org_id depois é fácil)

❌ Fundadores solo aprendendo (a complexidade pode ser demais)

Lições Aprendidas: Construa Para Sua Expertise

1. Conhecimento do Público Deve Guiar a Arquitetura

Não projete para usuários hipotéticos. Projete para usuários que você realmente entende.

Minha vantagem: 20 anos de experiência em agências significava que sabia exatamente o que as agências precisavam — isolamento de dados, escopo de cliente, acesso baseado em funções.

Abordagem errada: "Vamos construir para PMEs primeiro e adicionar agências depois quando as entendermos"

Abordagem certa: "Já entendo agências. Construa para elas agora enquanto é barato."

Se você tem profunda expertise em um segmento de mercado, use-a. Não adie para "mais simples primeiro."

2. Complexidade Cedo Bate Refatoração Tarde

Custo de arquitetura no Dia 2: 5 horas para redesenhar o modelo de dados.

Custo de arquitetura no Dia 60: 200 horas para refatorar tudo.

Diferença de 40X.

Se você está 80% certo de que precisará de multi-tenancy, construa cedo. Quanto mais você espera, mais caro fica.

3. Desafio Técnico Pode Ser Motivação

Esse é pessoal: eu *queria* construir algo difícil.

Arquitetura multi-tenant com políticas RLS, roteamento de schema e isolamento de dados adequado — isso é interessante. Me manteve engajado nas partes difíceis.

Se você é um fundador solo, não subestime motivação. Construir algo que te desafie pode valer mais do que lançar mais rápido.

4. Arquitetura Habilita Modelos de Negócio

Multi-tenancy não foi apenas uma decisão técnica. Habilitou:

- Faixas de preço para agências (quando eu finalmente descobrir precificação)

- Oportunidades de white-label

- Potencial de vendas enterprise

- Contas de equipe para PMEs

Arquitetura = opcionalidade de negócios em forma de código.

5. Fundadores Solo Podem Construir Multi-Tenant

"Multi-tenancy é complexo demais para uma pessoa" → Falso.

Com ferramentas modernas (Supabase RLS, funções de banco de dados, desenvolvimento assistido por IA), fundadores solo podem construir multi-tenancy de nível enterprise.

Custo de tempo: 70 dias (meio período).

O que você ganha: Isolamento de dados real, não um hack do qual você se arrependerá depois.

Vale a pena se você é sério sobre servir a ambos os públicos

Pensamentos Finais

O Dia 2 foi cedo demais para saber se o STRAŦUM teria sucesso. Eu tinha um agente. Sem usuários. Sem validação. Só 20 anos de experiência em agências me dizendo o que as agências realmente precisam.

O cronograma estendido foi doloroso às vezes. Assistir outros lançamentos enquanto ainda estava depurando políticas RLS e escrevendo funções de roteador de banco de dados? Frustrante não começa a cobrir. Havia dias que eu questionava se a complexidade valia a pena.

Mas aqui está o que sei agora: construir para ambos os públicos desde o Dia 1 foi a decisão certa. Não por causa de algum cálculo inteligente de unit economics — ainda não sei qual precificação funcionará. Mas porque tenho a arquitetura para servir adequadamente a ambos os públicos.

Multi-tenancy no Dia 2 não foi apenas uma decisão técnica. Foi uma aposta em construir para usuários que eu realmente entendo, não usuários hipotéticos que descobriria depois.

Essa aposta valeu a pena?

Ainda estou em Alpha Privado com 15+ usuários. Ainda não tenho a resposta. Mas posso te dizer isto: quando uma agência entra em contato e pergunta "podemos usar isso para múltiplos clientes com isolamento de dados adequado?" posso dizer sim. Não preciso dizer "estamos trabalhando nisso."

Isso parece a fundação certa.

O tempo dirá se fui ambicioso ou apenas teimoso. (Provavelmente um pouco dos dois, honestamente.) :)

Você já fez uma aposta de arquitetura cedo que parecia ambiciosa demais na época — e valeu a pena? Adoraria ouvir sua história.

Abraços,

Chandler

A série de arquitetura do STRAŦUM: Essa decisão do Dia 2 foi só o começo. No Dia 67, tive que reconstruir toda a camada de multi-tenancy quando uma auditoria de segurança revelou falhas arquiteturais. Depois vieram 31 telas em branco por contexto de navegação perdido e a descoberta de que meu banco de dados estava tecnicamente correto mas 296x muito lento.

---

Construindo um SaaS multi-tenant? A arquitetura do STRAŦUM suporta clientes PME e Agência desde o Dia 1. Solicite acesso alpha em https://stratum.chandlernguyen.com/request-invitation

---

Ainda aprendendo que decisões arquiteturais são decisões de negócios disfarçadas. Ainda depurando políticas RLS. Ainda questionando minhas decisões do Dia 2 (mas menos agora). Mais aventuras de construção em https://www.chandlernguyen.com/.

---