Blog

“Lançar é um marco. Operar bem é o que mantém o software vivo.”

É comum um app sair do ar (ou “morrer aos poucos”) depois do lançamento por motivos que não têm nada a ver com o código em si: domínio expirou, certificado venceu, conta da nuvem ficou sem pagamento, SMS parou de funcionar, mapa deixou de carregar.

Este artigo foi escrito para clientes e times não técnicos entenderem, de forma simples, quais custos recorrentes existem, o que acontece se algum deles falhar e como organizar a aprovação mensal para evitar sustos.

O que você vai encontrar aqui

• Um mapa rápido do que gera custo recorrente (e por quê)
• Checklist mensal (simples) para a empresa não ser pega de surpresa
• Custos típicos: domínio/DNS, HTTPS, nuvem, SMS/e-mail, mapas, storage e monitoramento
• O que acontece quando não renova ou quando o pagamento falha
• Como definir “quem aprova” e “quem acompanha” o orçamento mensal
• Por que ter um time de operação/DevOps evita que o app fique obsoleto

“O app morreu” quase sempre significa “alguma dependência parou”

O app normalmente depende de vários serviços ao mesmo tempo:

• Um domínio (ex.: api.suaempresa.com) para a API e, muitas vezes, outro para o portal administrativo
• Um certificado HTTPS para trafegar dados com segurança
• Um servidor (ou vários) e um banco de dados
• Um serviço de e-mail transacional (recuperação de senha, notificações, onboarding)
• Um serviço de SMS/OTP (autenticação, confirmações)
• Mapas/geolocalização (quando o app usa endereços, rotas, lojas próximas etc.)
• Storage para arquivos (imagens, documentos) e backups
• Monitoramento e logs, para detectar problemas antes do cliente reclamar

A apresentação abaixo resume bem o tipo de necessidade que aparece logo após o lançamento:

Checklist mensal: o mínimo para não ter surpresa

Se a sua empresa não tem uma área técnica dedicada, tudo bem: você ainda consegue se proteger com um checklist básico (feito 1x por mês).

Dica: o checklist funciona melhor quando cada item tem um responsável (mesmo que não seja técnico) e um alerta de vencimento/limite.

Custos recorrentes mais comuns (e o que acontece se não cuidar)

Abaixo estão os itens mais frequentes em projetos de apps e sistemas. Nem todo projeto terá todos eles, mas quase sempre você terá “uma versão” de cada categoria.

1) Domínio e DNS (API, portal, links do app)

O domínio é o que transforma um IP em uma URL estável.

Exemplos comuns:

• api.suaempresa.com (API do app)
• admin.suaempresa.com (portal administrativo)
• app.suaempresa.com (site, landing page, web app)

O que entra como custo recorrente:

• Renovação do domínio (geralmente anual)
• Às vezes: serviço de DNS gerenciado (em provedores como Cloudflare, AWS, Google, Microsoft etc.)

O que acontece se não renovar:

• A API/portal ficam fora do ar (porque o endereço deixa de existir)
• Você pode perder e-mails do domínio
• Você não consegue emitir/renovar certificados HTTPS para esse endereço

Boas práticas simples:

• Ative auto-renovação e mantenha 2 pessoas com acesso (ex.: TI + financeiro)
• Garanta que o domínio esteja em nome da empresa (não de um ex-funcionário/terceiro)
• Use subdomínios (na maioria dos casos, não precisa comprar um novo domínio)

2) Certificado HTTPS (TLS)

Apps modernos trafegam dados sensíveis e, por padrão, esperam comunicação segura. Na prática, isso significa: API em HTTPS.

O que entra como custo recorrente:

• Certificado TLS/HTTPS (pode ser gratuito ou pago, depende da solução)
• Operação de renovação (mesmo quando é “gratuito”, alguém precisa garantir que a renovação aconteceu)

O que acontece se o certificado vencer:

• O app começa a falhar em chamadas para a API (“erro de conexão segura”)
• Portais web passam a exibir aviso de segurança no navegador
• Integrações podem parar silenciosamente

Boas práticas simples:

• Prefira certificados com renovação automática (ex.: por ferramenta/serviço)
• Configure alerta de expiração (ex.: 30 dias antes)
• Evite “gambiarras” como desativar validação de HTTPS no app (isso vira risco de segurança)

3) Nuvem / servidor (API, portal e rotinas)

Esse é o custo que mantém o sistema “respirando” (CPU, memória, rede).

O que entra como custo recorrente:

• Servidores/containers/serverless
• Tráfego de rede (principalmente se há upload/download de arquivos)
• Serviços auxiliares (fila, cache, CDN, gateway, balanceador)

O que acontece se o pagamento falhar:

• O provedor pode suspender recursos (ou limitar)
• O app fica lento, intermitente ou fora do ar

Boas práticas simples:

• Crie alertas de custo e defina um “teto” operacional (para evitar surpresa)
• Separe ambientes (produção vs homologação), com regras claras de quem mantém cada um
• Mantenha credenciais e acesso em local seguro (e documentado)

4) Banco de dados e backups

Banco de dados costuma ser o coração: se ele cai, o app “fica cego”.

O que entra como custo recorrente:

• Banco gerenciado ou servidor de banco
• Backups automáticos (storage) e retenção
• Replicação/alta disponibilidade (quando necessário)

O que acontece se não houver backup:

• Um incidente vira prejuízo: pode ser impossível recuperar dados
• Qualquer restauração vira “tentativa e erro” sob pressão

Boas práticas simples:

• Backup automático + política de retenção
• Teste de restore (pelo menos 1x por trimestre)
  Backup que nunca foi testado é aposta.

5) Storage (arquivos) e CDN (quando aplicável)

Fotos, documentos, relatórios, notas fiscais… tudo isso vai para algum lugar.

O que entra como custo recorrente:

• Armazenamento de objetos (arquivos)
• Tráfego e entrega (download)
• Políticas de retenção (guardar por quanto tempo?)

O que acontece se não controlar:

• O custo cresce “sem você perceber” (especialmente com mídia)
• Fica caro para migrar depois porque já está acoplado ao produto

Boas práticas simples:

• Defina limites e regras: tamanho máximo de upload, compressão de imagens, retenção
• Separe storage “do app” (produção) do storage “de backup”

6) E-mail transacional (recuperação de senha, avisos, onboarding)

Quase todo app precisa disparar e-mails: confirmação, troca de senha, recibos, avisos.

O que entra como custo recorrente:

• Serviço de envio (por volume)
• Configuração de autenticação de e-mail (SPF/DKIM/DMARC no DNS)

O que acontece se não configurar corretamente:

• O e-mail “até sai”, mas cai em spam
• Recuperação de senha vira uma dor (e vira suporte)

Boas práticas simples:

• Configure SPF/DKIM/DMARC (o time técnico normalmente orienta os registros DNS)
• Monitore taxa de entrega e rejeições
• Tenha um e-mail “de suporte” funcionando (mesmo que simples)

7) SMS / OTP (autenticação, confirmações)

SMS é custo que pega muita empresa de surpresa porque é “barato por unidade” e “caro em volume”.

O que entra como custo recorrente:

• Custo por envio (volume)
• Às vezes: custos de validação/registro do remetente (depende do país e do provedor)

O que acontece se não tiver saldo/limite:

• Usuário não recebe código e não consegue entrar (impacto direto no negócio)

Boas práticas simples:

• Defina limite mensal e alertas
• Evite SMS para tudo: use e-mail/push quando fizer sentido
• Trate reenvio com regras (ex.: cooldown) para evitar abuso

8) Mapas e geolocalização

Se o app tem endereços, lojas, rotas, entregas, raio de busca… mapas e geocoding entram no jogo.

O que entra como custo recorrente:

• APIs de mapas/places/geocoding (normalmente cobram por uso e exigem billing)
• Proteção de chaves (para evitar uso indevido)

O que acontece se billing for desativado ou a cota estourar:

• O mapa não carrega
• Endereço não “resolve” (geocoding)
• O app passa a parecer quebrado

Boas práticas simples:

• Restrinja chaves por domínio/app (evita uso indevido)
• Monitore consumo e configure alertas
• Use cache quando possível (ex.: endereços repetidos)

9) Monitoramento, logs e alertas

Esse item não “aparece para o usuário” — mas evita incêndio.

O que entra como custo recorrente:

• Ferramenta de logs/monitoramento (ou estrutura própria)
• Tempo de alguém olhando alertas e agindo (principalmente em incidentes)

O que acontece sem monitoramento:

• Vocês descobrem que está fora do ar quando o cliente reclama
• Bugs e lentidão viram “sensação” em vez de dado

Boas práticas simples:

• Alertas do básico: disponibilidade, erro 5xx, tempo de resposta, banco de dados
• Canal de incidentes e um responsável por acionar o time técnico

10) Contas de publicação (Apple/Google)

Mesmo depois do app publicado, as contas continuam sendo essenciais para publicar atualizações e manter tudo regular.

O que entra como custo recorrente:

• A conta Apple Developer é uma assinatura/renovação (e precisa ficar ativa para publicar updates)
• No Google Play, a inscrição é feita via console e a conta precisa ficar em conformidade e segura (2FA, dados da organização etc.)

O que acontece se deixar “expirar” ou perder acesso:

• Você perde capacidade de publicar novas versões (e isso trava melhorias e correções)

Boas práticas simples:

• Acesso sempre na empresa (não em e-mail pessoal)
• 2FA bem configurado com backup e “pessoa reserva”
• Processo claro de troca de responsáveis (quando alguém sai da empresa)

O custo mais importante: operação e melhoria contínua

Uma parte do custo recorrente não é “conta de serviço”. É capacidade de evoluir o software:

• Corrigir bugs
• Ajustar regras de negócio
• Melhorar performance
• Reagir a feedback de usuários
• Atualizar dependências e segurança
• Manter o app compatível com novas versões de iOS/Android

Esse ciclo é a base do DevOps (planejar, construir, testar, publicar, operar e monitorar):

E, na prática, as melhorias mais comuns depois do lançamento costumam ser estas:

Se você quiser apoio nessa fase, a X-Apps tem um serviço dedicado de Operação e DevOps, focado em manter o software relevante e saudável no médio e longo prazo: Conheça o serviço de Operação DevOps

Quem aprova orçamento mensal (e como evitar travar o time)

Para não virar “ping-pong” de aprovação, defina 3 papéis (simples):

1. Responsável pelo produto (negócio)
   Define prioridades e aprova o que entra no roadmap.
2. Responsável técnico (operação/DevOps)
   Acompanha alertas, riscos, consumo e garante que tudo está funcionando.
3. Aprovador financeiro (orçamento mensal)
   Garante que as contas estão em dia e que existe um teto de custo para os serviços variáveis.

Um fluxo que funciona bem:

• O time técnico manda um relatório mensal simples (o que consumiu, o que mudou, riscos)
• O financeiro tem um teto de aprovação (até X, aprova automático; acima de X, precisa validar)
• Incidentes críticos têm caminho rápido de aprovação (para não parar o negócio)

Usar o domínio que você já tem vs comprar um novo

Usar o domínio da empresa (com subdomínios) é o caminho mais comum — e geralmente o melhor.

Vantagens de usar o domínio existente:

• Não cria mais uma renovação para lembrar
• Mantém marca e comunicação alinhadas (api.suaempresa.com)
• Menos risco de alguém esquecer “aquele domínio do app”

Cuidados ao usar o domínio existente:

• Evitar mexer na zona DNS “sem controle” (use mudança registrada e com responsável)
• Ter pelo menos duas pessoas com acesso administrativo

Quando faz sentido comprar um domínio separado:

• Você quer isolar totalmente o app (ex.: empresa grande com governança rígida)
• Você quer um domínio específico para uma unidade/produto

Cuidados ao comprar outro domínio:

• Coloque em nome da empresa e ative auto-renovação
• Se não renovar, o impacto é grande: API e portal podem cair

Checklist final para aprovar internamente (copie e cole)

• Domínio com auto-renovação, acesso na empresa e contato atualizado
• Subdomínios definidos (API e portal)
• HTTPS com renovação automática e alerta de expiração
• Nuvem com pagamento ok e alertas de custo configurados
• Banco com backup automático + restore testado
• Storage com limites/retenção definidos
• E-mail transacional com SPF/DKIM/DMARC configurados
• SMS com limite, alertas e política de reenvio
• Mapas com billing e proteção de chaves
• Monitoramento ativo e responsável nomeado
• Processo mensal: quem acompanha e quem aprova

Se você quiser, podemos transformar esse checklist em um documento de “pronto para operar” do seu projeto e assumir a operação contínua junto com vocês.