Durante muito tempo, a promessa do SaaS foi bem simples.

Você usa o software. A gente cuida do resto.

Nós operamos a aplicação, escolhemos a infraestrutura, hospedamos o banco de dados, garantimos os backups e fazemos o produto evoluir.

O cliente compra um serviço pronto.

Essa promessa continua valendo. Mas, nas conversas com as grandes empresas, vejo aparecer cada vez mais pedidos que a fazem mudar de forma.

"Os dados podem ficar no nosso ambiente Azure?"

"Dá para usar o nosso próprio SQL Server?"

"Dá para usar as nossas próprias chaves de criptografia?"

"Dá para gerenciar os usuários e as permissões deles a partir do nosso IAM?"

"Dá para usar o nosso contrato e o nosso fornecedor de LLM?"

"Dá para usar o nosso fornecedor de e-mail ou de SMS?"

"Dá para mandar os eventos de segurança para o nosso SIEM?"

Esses pedidos podem parecer muito diferentes entre si.

Na prática, eles costumam contar a mesma coisa.

As grandes empresas querem continuar comprando SaaS, mas querem retomar o controle de alguns blocos.

E essa mudança não é só técnica ou regulatória.

Ela também é cultural.

Quando a cultura do cliente vira parte do produto

Vamos pegar um pedido bem simples:

"Quero saber quem entra na aplicação."

Tecnicamente, não é necessariamente uma funcionalidade espetacular.

Mas por trás dessa frase podem estar uma auditoria ISO, uma política de segurança, um time de cibersegurança, um SIEM central, um procedimento de investigação ou simplesmente uma cultura de empresa em que todo acesso precisa deixar rastro.

O mesmo vale para a gestão de usuários.

O cliente pode não querer administrar permissões dentro de cada SaaS que compra. Ele quer que as identidades, os grupos e às vezes as permissões sejam conduzidos a partir do IAM dele.

Dá para olhar alguns desses pedidos e concluir que eles não criam nenhum valor de negócio.

E seria verdade.

Mas seria passar longe do assunto.

O produto que construímos para resolver o problema de negócio do cliente é só uma parte do que ele compra de verdade.

É aí que a distinção entre core product e whole product se torna útil.

O core product concentra o que realmente faz o nosso valor: nosso conhecimento do negócio, nossas regras, nossos workflows, nossa orquestração, nossa capacidade de resolver um problema melhor do que uma alternativa.

O whole product é tudo o que precisa existir ao redor desse valor para que um cliente específico consiga efetivamente comprar, implantar e operar o produto.

O SSO provavelmente não é a nossa diferenciação.

O SIEM também não.

A residência dos dados também não.

A capacidade de usar o IAM do cliente também não.

Mas a ausência de qualquer um desses elementos pode ser suficiente para travar uma venda.

Eles não criam necessariamente o valor.

Eles permitem que esse valor entre na empresa.

"Quero usar o seu SaaS, mas manter o meu banco aqui dentro"

O caso mais interessante é provavelmente o do banco de dados.

Vamos imaginar um software de folha de pagamento.

Todo mundo entende na hora a natureza dos dados envolvidos: salários, contratos, informações pessoais, organização da empresa.

No modelo SaaS clássico, o fornecedor opera o software e o banco que vem junto.

Agora, imagine uma grande empresa que diz para a gente:

Queremos a sua aplicação, mas os dados precisam ficar num banco SQL Server ou Azure SQL dentro do nosso ambiente Azure.

Não é um pedido absurdo.

E, no nosso caso, ele é até coerente com o mercado que queremos atender: a imensa maioria dos clientes que miramos já vive dentro do ecossistema Microsoft.

O motor do SaaS continuaria operado pelo fornecedor.

Mas o banco dele poderia ficar hospedado no ambiente do cliente.

Por que um cliente pediria isso, se sabemos perfeitamente bem hospedar um banco?

Porque a pergunta dele não é necessariamente:

"Vocês são capazes de hospedar bem os meus dados?"

Ela pode ser:

"Os meus dados continuam sob o controle da minha organização?"

Às vezes o cliente quer que o recurso fique dentro da assinatura Azure dele.

Ele quer aplicar as regras de rede dele.

As políticas de segurança dele.

As chaves dele.

Os mecanismos de inventário dele.

Os controles dele.

Os padrões internos dele.

E, principalmente, poder dizer ao CISO dele, ao auditor dele ou à organização dele:

"Esses dados ficam aqui dentro."

Nem sempre é uma obrigação regulatória.

Pode ser simplesmente uma condição para que a empresa aceite o produto.

Controlar onde os dados ficam não é controlar o produto

Dar mais controle ao cliente introduz, ainda assim, uma fronteira que precisa ser preservada.

O motor de negócio continua com o fornecedor.

A propriedade intelectual dele continua com o fornecedor.

E, principalmente, a capacidade de fazer o produto evoluir precisa continuar com o fornecedor.

Vamos pegar as migrações de banco.

Suponha que a gente adicione uma funcionalidade que exige uma nova coluna, um índice ou uma mudança de schema.

Se cada subida para produção exige mandar um procedimento para o time do cliente, esperar uma validação, reservar uma janela de manutenção e depois verificar na mão se a migração foi aplicada, o modelo não para de pé.

Ele já é dificilmente compatível com um SaaS que entrega várias vezes por semana.

E vai ser ainda menos amanhã.

O desenvolvimento de software assistido por IA já aumenta a nossa capacidade de produzir, testar e modificar software. É razoável imaginar que a cadência de entrega vai continuar subindo.

Construir hoje uma arquitetura que exige mais intervenções humanas em cada cliente a cada evolução iria exatamente no sentido contrário.

Rapidinho, um cliente aplica a migração na terça.

Outro espera até sexta.

Um terceiro empurra para o mês seguinte.

Aí você fica com várias versões do motor, vários estados do schema e uma complexidade que cresce a cada release.

E acaba perdendo uma das vantagens estruturais do SaaS: fazer um produto comum evoluir continuamente para todos os clientes.

Só que o cliente que pede para manter os dados dentro do ambiente dele não está necessariamente pedindo para gerenciar as nossas migrações.

Ele quer controle sobre onde os dados dele vivem.

Não sobre como o nosso produto evolui.

A fronteira fica então bem simples:

o cliente controla onde os dados dele vivem; o fornecedor controla como o produto evolui.

O BYO-Database só é realmente compatível com o SaaS se as migrações puderem continuar automatizadas e conduzidas pelo fornecedor, dentro de um enquadramento de segurança aceito pelo cliente.

O controle também desloca as responsabilidades

Mover o banco para o ambiente do cliente traz outra consequência.

Uma parte da infraestrutura de que o nosso serviço depende deixa de estar inteiramente sob o nosso controle.

E no dia em que a aplicação cair, essa distinção fica bem concreta.

É o nosso motor?

O banco SQL Server do cliente?

O Azure?

Uma regra de rede que acabou de ser alterada?

Um certificado?

Uma configuração de IAM?

Uma saturação de conexões?

Uma quota?

Um problema de latência?

Dizer:

"O banco está no cliente, o problema não é nosso"

não funciona.

Para o usuário, é o nosso SaaS que parou de funcionar.

O BYO impõe então uma exigência que me parece inegociável: precisamos conseguir monitorar o banco e a conectividade dele o suficiente para entender de onde vem um incidente.

Isso não quer dizer administrar toda a infraestrutura no lugar do cliente.

Quer dizer ter os sinais necessários: disponibilidade, latência, erros de conexão, saturação, estado de saúde, eventos úteis para o diagnóstico.

Essa observabilidade é indispensável do ponto de vista operacional.

Mas também é do ponto de vista contratual.

Se o nosso SLA exclui as quedas provocadas por um recurso sob controle do cliente, precisamos ser capazes de determinar de forma objetiva que o incidente veio mesmo desse recurso.

A divisão de responsabilidades só existe de verdade quando dá para atribuir os incidentes.

O cliente paga o banco dele. Mesmo assim o SaaS dele pode custar mais caro.

É aí que aparece um paradoxo interessante.

O cliente pode pagar diretamente o Azure SQL ou o SQL Server dele.

Dá então para pensar:

Já que ele mesmo paga o banco, o nosso SaaS deveria custar menos.

Não necessariamente.

Nosso custo de serviço não se limita ao preço da infraestrutura.

Dar suporte a bancos dentro dos ambientes dos clientes pode nos obrigar a lidar com mais variantes.

Versões diferentes.

Restrições de rede diferentes.

Mecanismos de replicação.

Backups.

Snapshots.

Restaurações.

Permissões.

Monitoramento.

Configurações específicas.

E, principalmente, mais cenários para entender quando alguma coisa para de funcionar.

Terceirizar um recurso pode, portanto, reduzir o nosso custo direto de infraestrutura e ao mesmo tempo aumentar o nosso custo de serviço.

Os backups ilustram bem essa divisão.

Se nos comprometemos a gerenciar os backups e a garantir a restauração de um banco que fica no ambiente do cliente, assumimos uma responsabilidade a mais.

Ela exige tecnologia.

Testes.

Monitoramento.

Procedimentos de recuperação.

Essa responsabilidade tem, portanto, um custo, e precisa ser cobrada.

Do outro lado, o cliente pode escolher gerenciar os próprios backups.

Nesse caso, as responsabilidades precisam ficar explícitas: retenção, qualidade dos backups, restauração e consequências de um backup inutilizável passam a ser dele.

O BYO não faz as responsabilidades desaparecerem.

Ele só obriga a dizer com muito mais precisão quem carrega quais.

Nem todos os blocos precisam ficar com a gente

Depois desse raciocínio, o banco de dados aparece como o caso mais difícil de um fenômeno mais amplo.

Uma pergunta simples ajuda a pensar os outros blocos:

se eu trocar esse fornecedor por outro, o valor do meu serviço muda?

Vamos pegar o envio de e-mails.

Se trocarmos o nosso fornecedor de e-mail pelo do cliente, o valor de negócio do nosso produto muda?

Provavelmente não.

A mensagem continua sendo enviada na hora certa porque o nosso motor decidiu que ela deveria ser.

O mesmo vale para um SMS.

O mesmo vale, em certos casos, para um LLM.

Nosso produto pode fornecer por padrão um modelo de IA.

Mas uma grande empresa pode preferir usar o próprio contrato Azure OpenAI, as próprias chaves ou um fornecedor já aprovado.

Se o nosso valor está no workflow de negócio, no contexto, nas regras, nos dados e na orquestração, trocar o modelo de execução não deveria deslocar o coração do produto.

Isso não quer dizer que todos os fornecedores sejam perfeitamente intercambiáveis.

Um modelo pode ter desempenho melhor que outro.

Um fornecedor de e-mail pode ter uma entregabilidade melhor.

Mas a pergunta certa continua sendo:

é esse bloco que carrega o valor pelo qual o cliente compra o nosso produto?

Se trocar um fornecedor destrói o valor do serviço, ele provavelmente está perto demais do nosso core product para ser livremente substituível.

Se a troca dele não muda o valor de negócio fundamental, ele pode virar candidato à configuração, à substituição ou ao BYO.

Nem toda substituição custa a mesma coisa

Ainda existe uma diferença importante.

Um gateway de e-mail é relativamente stateless.

O mesmo vale para um provider de SMS.

E um LLM também pode ser, desde que a memória durável, o contexto de negócio e as decisões fiquem dentro do nosso produto.

Um banco de dados é diferente.

Ele contém o estado durável do sistema.

Você não passa de um SQL Server para outro só trocando uma chave de API.

É preciso migrar os dados.

Garantir a consistência deles.

Prever a recuperação.

Gerenciar os backups.

Às vezes a replicação.

A substituibilidade não é, portanto, binária.

É um gradiente.

Um bloco pode não ser diferenciante para o nosso produto e ainda assim ser extremamente importante do ponto de vista operacional.

Isso vale especialmente para o banco.

Não transformar o whole product num catálogo

A partir daí, a tentação seria construir todas as possibilidades.

Azure.

AWS.

GCP.

SQL Server.

PostgreSQL.

Oracle.

Cinco fornecedores de IA.

Três fornecedores de e-mail.

Quatro gateways de SMS.

Provavelmente seria um erro.

A pergunta certa não é:

"O que conseguimos tecnicamente suportar?"

E sim:

"O que precisamos suportar para os clientes que escolhemos atender?"

Se 90% das grandes empresas que miramos já estão estruturadas em torno de Microsoft e Azure, começar por Azure e SQL Server faz sentido.

Não porque o SQL Server seja intrinsecamente melhor que outro banco.

Mas porque essa configuração é a que provavelmente maximiza a nossa capacidade de vender no mercado que miramos.

Do outro lado, suportar um banco ou uma nuvem que ninguém no nosso segmento pede não acrescenta necessariamente valor.

A largura do suporte tecnológico não é um objetivo em si.

Ela precisa seguir o posicionamento comercial.

O whole product não é um checklist universal do "SaaS enterprise perfeito".

Ele é a tradução concreta da pergunta:

o que precisamos acrescentar em volta do nosso core product para que os clientes que escolhemos atender consigam realmente comprá-lo?

Entender a necessidade por trás do pedido

Isso não quer dizer que a gente deva responder literalmente a cada pedido do cliente.

Quando uma grande empresa diz:

Quero os meus dados no meu Azure.

A resposta certa não é imediatamente:

Combinado, vamos construir o BYO-Database.

É preciso entender por quê.

É uma obrigação regulatória?

Uma exigência de residência?

Uma política do CISO?

Uma necessidade de controlar as chaves?

Uma restrição de auditoria?

Uma vontade de reversibilidade?

Ou simplesmente uma cultura segundo a qual os dados sensíveis precisam ficar sob controle direto da empresa?

A solução pode depender dessa resposta.

Uma região dedicada às vezes basta.

Customer Managed Key às vezes basta.

Um ambiente single-tenant às vezes basta.

Em outros casos, vai ser preciso realmente hospedar o banco no tenant do cliente.

Entender por que o cliente pede controle permite propor o nível certo de controle.

Mas isso não muda a constatação inicial.

Se você decide vender para grandes empresas, a cultura de governança delas faz parte do mercado.

Você não pode querer os volumes delas, os orçamentos delas e os contratos delas e ao mesmo tempo tratar as restrições de auditoria, de segurança ou de controle delas como detalhes chatos.

Isso não é uma estratégia de infraestrutura

Esse é provavelmente o ponto mais importante.

À primeira vista, todo esse assunto parece uma discussão de arquitetura.

Onde hospedar o SQL Server?

Como conectar o motor?

Como migrar o schema?

Como monitorar?

Como gerenciar os backups?

São perguntas legítimas.

Mas elas vêm depois de outra:

quais clientes decidimos atender?

O core product cria o valor.

O posicionamento escolhe o mercado.

E o whole product torna o core product compatível com a realidade desse mercado.

Se as grandes empresas que queremos atender têm uma cultura forte de controle dos dados, das identidades, das chaves e dos fornecedores delas, então algumas dessas capacidades provavelmente precisam virar parte do nosso whole product.

Não porque o BYO seja melhor que o full-managed.

O full-managed provavelmente deve continuar sendo a escolha padrão.

Ele continua mais simples de operar, mais homogêneo e mais fácil de fazer evoluir.

O BYO vira uma opção quando o mercado justifica.

E o escopo dele precisa ser decidido da mesma forma.

Não precisamos tornar cada componente intercambiável.

Não precisamos suportar todas as tecnologias.

Precisamos, acima de tudo, identificar as restrições que realmente impedem os clientes que escolhemos atender de comprar o nosso produto.

E depois decidir quais delas queremos remover.

O BYO não é, portanto, antes de mais nada uma estratégia de infraestrutura. É uma decisão de whole product e de posicionamento comercial.

A consequência técnica pode ser um SaaS mais modular.

O motor continua sob o nosso controle.

Alguns dados ficam no cliente.

Alguns fornecedores se tornam substituíveis.

Algumas responsabilidades mudam de mão.

Mas não é esse o ponto de partida.

O ponto de partida continua sendo o mercado.

A ideia não é dar todas as escolhas possíveis a todos os clientes. A ideia é construir o whole product que permite ao nosso core product ser comprado pelos clientes que decidimos atender.