Software House: Como Hospedar e Revender Sistema dos Clientes em Cloud Brasileira (Modelo de Negócio 2026)

Software house brasileira que desenvolve sistema sob medida (ERP customizado, sistema vertical, SaaS B2B nacional) enfrenta a mesma decisão estratégica em algum momento: onde hospedar o sistema dos clientes? Cada cliente cuida da própria infra (caos operacional), ou a software house assume hospedagem e revende (modelo SaaS com receita recorrente)?

Quem opta por hospedar e revender vira essencialmente um provedor de SaaS pra cliente final — com margem recorrente, controle total da experiência, e responsabilidade técnica que precisa ser bem dimensionada. Esse guia é pra sócio, CTO ou comercial de software house brasileira avaliando esse modelo em 2026. Cobre os 3 modelos de hospedagem, modelos de cobrança, arquitetura técnica, contratos, e checklist pra avaliar provedor cloud.

Por que software house brasileira deve revender hospedagem em 2026

Cliente final do sistema da software house frequentemente NÃO quer gerenciar infraestrutura. Quer login, senha e o sistema funcionando — independente de onde roda. Modelo de hospedagem revendida cria 5 vantagens objetivas:

• Receita recorrente previsível: mensalidade mensal por cliente, soma à receita de licença. Software house de 30 clientes pode ter receita mensal robusta só de hospedagem.
• Controle total da experiência: versão do sistema, backup, performance, atualizações — tudo controlado pela software house, não pelo cliente final.
• Margem em cima do custo de infra: negocia custo baixo com provedor cloud, revende com margem ao cliente final. Margens típicas de 30-100% sobre custo direto.
• Menos atrito comercial: cliente final não precisa contratar cloud separado, lidar com TI próprio, debugar infraestrutura. Pacote único — software + infra.
• Suporte centralizado: software house vê todos os clientes no mesmo painel, atualiza tudo de uma vez, debugga performance globalmente.

3 modelos de hospedagem revendida em 2026

Modelo 1: VPS isolado por cliente (per-tenant)

Cada cliente final tem seu próprio VPS isolado — banco de dados separado, arquivos separados, ambiente independente.

• Vantagens: isolamento total (incidente de um cliente não afeta outro), customização fácil por cliente (versão diferente, plugin específico), backup independente, encerrar contrato é simples (deleta o VPS)
• Desvantagens: custo maior por cliente (cada um paga seu VPS), gestão de N VPSs (atualizar 30 VPSs um a um se não tiver automação), eficiência menor de hardware
• Quando faz sentido: sistema que exige customização real por cliente, software house pequena/média começando, vertical regulado que exige isolamento

Modelo 2: Multi-tenant em servidor compartilhado

Vários clientes no mesmo servidor — aplicação compartilhada, isolamento por banco de dados (ou schema dentro do banco).

• Vantagens: custo por cliente muito menor (1 servidor pra 50 clientes), atualização de versão centralizada, eficiência alta de recursos, escala horizontal mais simples
• Desvantagens: exige arquitetura multi-tenant bem feita na aplicação (separação de dado por tenant, controle de acesso), incidente de um cliente pode afetar performance dos outros, customização por cliente é difícil
• Quando faz sentido: SaaS verdadeiro, sistema padronizado (mesma versão pra todos), software house com 50+ clientes, vertical onde isolamento físico não é exigido

Modelo 3: Híbrido por porte (VPS compartilhado + dedicado pra grandes)

Clientes pequenos no multi-tenant compartilhado, clientes grandes em servidor dedicado próprio (com mensalidade mais alta), clientes regulados em ambiente isolado.

• Vantagens: custo otimizado por porte, atende perfis diferentes com a mesma operação, oferece "upgrade" como diferencial comercial pra cliente grande
• Desvantagens: complexidade operacional maior (3 arquiteturas), exige automação pra manter consistência
• Quando faz sentido: software house com base diversa (clientes de 10 a 500 usuários), vertical com necessidades mistas (algumas empresas exigem isolamento, outras não)

Maioria das software houses brasileiras em 2026 começa com Modelo 1 (per-tenant) pela simplicidade e migra pra Modelo 3 (híbrido) quando passa de 50-100 clientes.

Modelos de cobrança pra cliente final

Cobrança per-tenant (custo de infra + margem)

Software house revende a hospedagem como item separado na fatura — "Licença R$ X + Hospedagem R$ Y". Margem típica de 30-100% sobre o custo direto de infra. Vantagem: cliente final entende o que paga. Desvantagem: cliente compara preço de hospedagem com terceiros.

All-inclusive (sistema + infra como SaaS único)

Cobrança única "SaaS R$ Z/mês por usuário ou por empresa" — sistema + infra + suporte tudo embutido. Margem maior se infra é bem otimizada (multi-tenant), prejuízo se cliente cresce muito sem aumentar plano. Vantagem: comercialmente mais simples, cliente não compara preço de infra. Desvantagem: software house assume risco de variação de uso.

Híbrido (plano básico SaaS + custo extra de recursos)

Plano básico SaaS cobre infra padrão. Cliente que precisa mais (mais usuários, mais storage, alta performance) paga adicional. Vantagem: balanceia previsibilidade com flexibilidade. Desvantagem: precisa de painel/sistema interno pra medir uso por cliente.

Arquitetura técnica: o que precisa ter

Software house séria que hospeda cliente precisa de 6 elementos técnicos:

1. Painel multi-tenant centralizado: uma única conta na cloud com todos os servidores dos clientes, organizados por tag/projeto/cliente
2. Backup individual por cliente com retenção configurável, restore granular
3. Monitoramento por cliente: métricas separadas (CPU, RAM, disco, latência, erros) pra debugar incidente específico
4. Automação de provisionamento: novo cliente fechou → script ou Terraform cria VPS, instala sistema, configura DNS, gera credenciais — sem manual
5. Atualização de versão centralizada: mecanismo pra atualizar 1, alguns ou todos os clientes ao mesmo tempo, com rollback
6. Documentação de cada cliente: qual versão roda, qual customização tem, qual o SLA contratado

Software house que não tem esses 6 elementos opera no improviso — funciona com 5 clientes, mas vira inferno operacional com 30+.

Contratos: o que precisa estar no contrato com cliente final

• SLA explícito de disponibilidade (frequentemente menor que SLA do provedor cloud — software house adiciona camada de risco)
• Política de backup documentada (frequência, retenção, restore SLA)
• Janela de manutenção avisada com antecedência
• Política de atualização (quando software house pode atualizar, em que horário, com aprovação ou automática)
• Política de cancelamento e retirada de dados — cliente quer sair, recebe dump do banco e arquivos em 30 dias
• DPA pra LGPD — software house é Operador do cliente, cliente é Controlador. Documenta cadeia.
• Limites de uso — quantos usuários, GB de storage, requisições/min cabem no plano
• Política de incidente: comunicação em quanto tempo, plano de ação, escalonamento

LGPD na operação de software house revendendo cloud

Software house hospedando cliente assume papel de Operador (art. 5, VII da LGPD). Cliente final é o Controlador dos dados pessoais que estão no sistema. Provedor cloud (Audaks ou outro) é Sub-Operador da software house.

A cadeia precisa estar documentada:

• Cliente final ↔ Software house: DPA com cláusulas LGPD, software house assume responsabilidade de Operador
• Software house ↔ Provedor cloud: DPA com cláusulas equivalentes, provedor cloud assume responsabilidade de Sub-Operador

Sem essa cadeia documentada, ANPD em fiscalização aponta como descumprimento. Provedor cloud decente fornece DPA pronto pra software house anexar ao contrato com cliente final.

Como precificar revenda de cloud em 2026 (cálculo prático)

Software house calcula o preço da revenda em 3 passos:

1. Custo direto de infra por cliente

Calcula quanto custa hospedar UM cliente no provedor cloud: servidor (compartilhado ou dedicado), backup, monitoramento, banda. Em multi-tenant, divide o custo do servidor entre N clientes. Em per-tenant, é o custo do VPS individual.

2. Margem operacional

Adiciona margem pra cobrir trabalho de gestão (suporte, atualização, debug, escalada de incidentes) + risco operacional (cliente que consome mais que o esperado, incidente do provedor, etc). Margens típicas: 30-50% pra modelo per-tenant, 50-100% pra modelo multi-tenant (já que ganho de eficiência fica na software house).

3. Posicionamento de mercado

Compara com preço que o cliente pagaria contratando provedor cloud direto + esforço de gerenciar. Software house cobra na faixa "menor que cliente fazendo sozinho com TI próprio" mas "maior que provedor cloud puro" — porque entrega gerenciamento.

Exemplo simplificado: VPS de cliente custa R$ X/mês na Audaks. Software house cobra R$ X * 1,7 do cliente final como item "Hospedagem" — R$ X de custo + R$ X * 0,7 de margem operacional. Cliente paga uma fração do que pagaria contratando provedor direto + um técnico próprio pra gerenciar.

Provedor cloud ideal pra software house brasileira

Software house séria avalia provedor cloud em 8 critérios além do preço:

1. Painel multi-tenant nativo — gerencia 30 servidores em uma única conta, com tags/projetos por cliente
2. API ou Terraform pra automação — provisiona cliente novo via script, não manual
3. NF brasileira emitida automaticamente — software house deduz no MEI/Simples/Lucro Presumido
4. Suporte engineer em português 24h — incidente de cliente final tem que ser resolvido sem fuso horário
5. DPA pra LGPD pronto pra anexar ao contrato com cliente final
6. Marketplace 1-clique pra apps comuns (WordPress, n8n, Chatwoot, Evolution API) — reduz tempo de setup de novo cliente
7. Backup configurável por servidor com retenção independente
8. Pagamento em Real, sem IOF, sem variação cambial — previsibilidade orçamentária

Cloud internacional (AWS, Azure) atende parte desses critérios mas falha em pagamento (dólar+IOF), suporte (inglês) e marketplace BR. Cloud brasileira nativa atende todos.

Por que considerar Audaks pra software house brasileira

A Audaks Cloud tem proposta específica pra software house e agência digital brasileira — formalizada em página dedicada /software-house:

• Painel multi-tenant pra gerenciar dezenas de clientes numa única conta
• API REST pra automação de provisionamento
• NF brasileira automática, pagamento em Real, sem IOF
• Suporte engineer 24h em português via WhatsApp
• DPA pra LGPD disponível pra anexar ao contrato com cliente final
• Marketplace 1-clique pra WordPress, n8n, Evolution API, Chatwoot, Typebot, NextCloud, Portainer, etc.
• Backup configurável por servidor com retenção independente
• Datacenter Tier III em SP com peering IX.br
• VPS pra clientes pequenos + dedicado pra clientes grandes — mesma operação

Detalhe de migração e revenda em onde hospedar sistema dos clientes e cloud pra software house.

Perguntas frequentes sobre software house revendendo cloud

Software house precisa ser MEI, ME ou LTDA pra revender cloud?

Qualquer regime, mas com implicações fiscais distintas. MEI tem teto de faturamento; SIMPLES Nacional cobra ISS sobre revenda de infra; Lucro Presumido tem PIS/COFINS reduzido pra revenda de tecnologia. Consulte contador antes de estruturar o modelo — pode mudar significativamente a margem líquida.

Posso emitir NF do cliente final em meu CNPJ e ter custo Audaks no meu CNPJ?

Pode. Esse é o modelo padrão de revenda — Audaks emite NF pra software house (CNPJ A), software house emite NF pra cliente final (CNPJ B). Software house apura imposto sobre a diferença (margem). Modelo é legalmente reconhecido como revenda de SaaS/infra.

Multi-tenant ou per-tenant: qual é melhor pra software house começando?

Per-tenant pra começar (mais simples, isolamento garantido por design). Multi-tenant a partir de 30-50 clientes ativos pra ganhar eficiência. Híbrido (mistura) pra software house madura com base diversa.

Como cobrar do cliente final pela hospedagem?

3 modelos: (1) item separado "Hospedagem R$ X/mês" — transparente, cliente entende; (2) embutido no SaaS "Plano Profissional R$ Y/mês" — mais simples comercialmente; (3) híbrido com plano básico + add-ons (mais usuários, storage extra). Escolha depende do perfil do cliente final.

O que faço se um cliente final quer sair e levar os dados?

Documenta no contrato: prazo de aviso prévio (30 dias é padrão), formato de entrega de dado (dump SQL + arquivos via download seguro ou Object Storage), responsabilidade de migração (cliente assume, software house ajuda mediante hora técnica). Tem que estar documentado pra evitar conflito quando acontecer.

Sou Operador ou Controlador na LGPD se hospedo sistema do cliente?

Operador. Cliente final (empresa contratante) é o Controlador dos dados pessoais que estão no sistema. Software house processa esses dados em nome do cliente — papel de Operador. Provedor cloud é Sub-Operador. A cadeia toda precisa ter DPA assinado.

Posso ter alguns clientes em servidor compartilhado e outros em dedicado próprio?

Pode, e é o modelo recomendado pra software house madura. Clientes pequenos (poucos usuários, pouco storage) ficam em servidor compartilhado com isolamento por banco. Cliente grande (banco pesado, muitos usuários, requisito de SLA mais alto) vai pra dedicado próprio com cobrança maior. Software house diferencia produto por porte.

Como automatizo provisionamento de cliente novo no Audaks?

Via API REST ou Terraform. Software house tem fluxo: cliente fecha → sistema interno chama API Audaks → cria VPS, configura DNS, instala stack, gera credenciais → notifica cliente. Tudo em poucos minutos, sem intervenção manual. Provedor cloud sério oferece essa API.

O que cobre o suporte Audaks pra software house?

Hardware, infraestrutura, rede, datacenter, plataforma cloud — tudo que está sob controle do provedor. Aplicação dos clientes (sistema da software house) é responsabilidade da própria software house. Suporte 24h via WhatsApp atende incidentes de infraestrutura com engenheiro brasileiro.

Posso revender backup como item separado na fatura?

Pode, e é o padrão. Software house contrata backup corporativo Audaks com retenção configurável, e cobra do cliente final como item "Backup R$ X/mês". Margem em cima do custo direto. Confira guia de backup corporativo.