Produto no ar ≠ produto acabado. Primeiros 60 dias = período crítico de ajustes.
A CEO de uma clínica de fisioterapia me ligou no 3º dia após o lançamento do app de agendamentos: “Tem um bug crítico — cliente consegue agendar sessão mesmo quando fisioterapeuta já está com horário ocupado. Dois clientes chegaram no mesmo horário hoje e tivemos que remarcar um deles.”
Respondi em 15 minutos no Slack. Fix no ar em 2 horas. Zero custo adicional — estava coberto pela garantia de 60 dias.
No dia 42, ela pediu para mudar a cor do botão de confirmação de agendamento (de azul para verde) porque “ficaria mais intuitivo”. Ajustamos em 30 minutos. Também coberto.
No dia 68, ela queria adicionar integração com WhatsApp Business (não estava no escopo original). Isso não estava coberto — era nova feature, fora da garantia.
A linha entre “bug coberto” e “feature não coberta” pode parecer clara no papel, mas na prática gera confusão. Este artigo documenta exatamente o que a garantia de 60 dias cobre, o que não cobre, e como funciona a manutenção contínua após esse período.
Por que 60 dias (e não 30 ou 90)?
30 dias é pouco. Bugs de volume só aparecem com uso real — e leva 3-4 semanas para acumular dados suficientes. Problemas de performance, edge cases complexos e gargalos só ficam evidentes após o primeiro mês.
90 dias é longo demais para chamá-lo de “garantia”. Com 3 meses, o cliente já deveria estar operando de forma estável e qualquer ajuste seria manutenção evolutiva, não correção de lançamento.
60 dias é o ponto ideal: tempo suficiente para identificar e corrigir todos os bugs relevantes, ajustar UX baseado em uso real e estabilizar o produto para operação contínua.
Garantia de 60 dias cobre:
- ✅ Correção de bugs (ilimitado)
- ✅ Ajustes pequenos de UX
- ✅ Suporte técnico (resposta menor que 24h)
- ✅ 1 revisão de performance
O que NÃO cobre:
- ❌ Novas features (fora do escopo original)
- ❌ Integrações adicionais
- ❌ Mudanças de arquitetura
O que é considerado “bug”?
Bug = Algo que deveria funcionar (conforme spec) mas não funciona.
Exemplos válidos (cobertos):
- Botão de “Salvar” não salva dados
- E-mail de confirmação não chega
- Página quebra em Safari (funcionava em Chrome)
- Pagamento aprovado mas pedido não é criado
- Upload de fotomaior que 5MB trava (spec dizia suportar 10MB)
Não é bug (não coberto):
- “Queria que botão fosse verde, não azul” (mudança de design, não bug)
- “Faltou campo CPF no cadastro” (nova feature, não estava no escopo)
- “Site lento com 10K usuários” (não testamos para essa escala)
SLA (Service Level Agreement)
Classificação de prioridade:
P0 - Crítico (sistema fora do ar):
- Resposta: menor que 2h
- Resolução: menor que 8h
- Exemplos: Deploy quebrado, banco down, pagamentos não funcionam
P1 - Alto (funcionalidade core quebrada):
- Resposta: menor que 8h
- Resolução: menor que 24h
- Exemplos: Login não funciona, checkout com erro
P2 - Médio (funcionalidade secundária):
- Resposta: menor que 24h
- Resolução: menor que 72h
- Exemplos: Notificações atrasadas, exportar PDF quebrado
P3 - Baixo (cosméticos, edge cases):
- Resposta: menor que 48h
- Resolução: menor que 7 dias
- Exemplos: Alinhamento de texto, typo, tooltip errado
Ajustes de UX cobertos
Pequenos ajustes (sim):
- Mudar cor/tamanho de botão
- Ajustar espaçamento, margens
- Melhorar mensagem de erro
- Adicionar tooltip
- Reordenar elementos
Mudanças grandes (não):
- Redesenhar tela completa
- Mudar fluxo de navegação
- Adicionar wizard multi-step (onde era formulário único)
Regra prática: Se leva menor que 2h, é ajuste. Se leva maior que 4h, é feature nova (cobrado separado).
Modelo de manutenção contínua
Após 60 dias de garantia, ofereço 3 planos:
Plano 1: Suporte Básico (R$ 3K/mês)
Inclui:
- Correção de bugs (ilimitado)
- Suporte técnico (resposta menor que 48h)
- 1 deploy/mês
- Atualizações de segurança
Não inclui:
- Novas features
- Ajustes de UX
Para quem: Produto estável, poucas mudanças.
Plano 2: Manutenção + Evolução (R$ 8K/mês)
Inclui:
- Tudo do Plano 1
- 20h/mês de desenvolvimento (features, melhorias)
- Deploys ilimitados
- Reunião mensal de roadmap
Para quem: Produto em evolução, 1-2 features novas/mês.
Plano 3: Suporte Premium (R$ 15K/mês)
Inclui:
- Tudo do Plano 2
- 40h/mês de desenvolvimento
- SLA prioritário (resposta menor que 4h)
- Code review + pair programming
Para quem: Produto crítico, time interno pequeno.
Processo de abertura de chamado
1. Cliente reporta via:
- E-mail: suporte@orientme.com.br
- Slack (canal dedicado)
- Sistema de tickets (Linear, Jira)
2. Ticket criado com:
- Título claro (“Checkout quebrado ao pagar com PIX”)
- Descrição (passos para reproduzir)
- Prints/vídeo
- Prioridade (P0-P3)
3. Triagem (menor que 2h):
- Confirmo prioridade
- Estimo tempo de resolução
- Comunico ao cliente
4. Resolução:
- Fix desenvolvido
- Deploy em staging
- Cliente valida
- Deploy em produção
5. Fechamento:
- Cliente confirma resolução
- Post-mortem (se P0/P1)
Post-mortem (para incidents críticos)
Template:
# Incident: [Título]
**Data**: 2026-09-15 14h20
**Duração**: 37 minutos
**Severidade**: P0 (sistema fora do ar)
## Timeline
- 14:20: Alerta no Sentry (500 errors)
- 14:22: Identificado causa raiz (migration quebrada)
- 14:35: Rollback do deployment
- 14:57: Sistema normalizado
## Root Cause
Migration adicionou coluna NOT NULL sem default value.
Queries antigas falhavam ao tentar INSERT.
## Impact
- 142 usuários afetados
- 7 transações falharam (reprocessadas)
- R$ 840 em receita temporariamente bloqueada
## Preventive Actions
- [ ] Adicionar test de migration em staging
- [ ] Nunca adicionar NOT NULL sem default (lint rule)
- [ ] Rollback automático se error rate maior que 5%Transição para manutenção interna
Quando fazer sense:
- Time interno cresceu (2+ devs)
- Produto maduro (poucas mudanças)
- Quer reduzir custo (manutenção interna < externa)
Processo de handoff:
Semana 1-2: Documentação
- README completo
- Arquitetura documentada
- Runbooks (como fazer deploy, rollback, etc)
Semana 3-4: Knowledge transfer
- 4 sessões de 2h (pair programming)
- Dev interno faz shadowing
- Revisamos código crítico
Semana 5: Supervisão
- Dev interno faz primeiro deploy sozinho
- Estou disponível para dúvidas
- Transferência de acessos (AWS, Vercel, etc)
Pós-handoff:
- Suporte on-demand (R$ 250/h)
- Consultoria pontual (arquitetura, escalabilidade)
FAQs
“Posso cancelar manutenção a qualquer momento?” Sim, com 30 dias de aviso.
“Se eu cancelar, posso voltar depois?” Sim, mas tarifa de reativação (R$ 2K para re-onboarding).
“20h/mês não usadas, posso acumular?” Não. Horas resetam todo mês. (Evitar acúmulo de débito técnico.)
“Urgência fora do horário comercial, vocês atendem?” P0/P1: Sim (24/7 via PagerDuty). P2/P3: Não (aguarda horário comercial).
“Quanto custa adicionar feature fora do plano?” R$ 180/h (mínimo 4h). Ou upgrade para plano superior.
Case real: clínica médica (Salvador) — Da garantia à manutenção evolutiva
Perfil do projeto:
- App de telemedicina (agendamento + videoconsulta + prontuário)
- 3 médicos, 180 pacientes no primeiro mês
- Timeline: 10 semanas de dev + go-live
Investimento inicial: R$ 125K (desenvolvimento completo)
Fase 1: Primeiros 60 dias (garantia, R$ 0 adicional)
Semana 1-2 pós-lançamento: bugs críticos detectados
| Bug | Prioridade | Tempo de resolução | Coberto? |
|---|---|---|---|
| Videoconferência não iniciava em iPhone 12 | P0 | 4h | ✅ Sim |
| Notificação de consulta não chegava | P1 | 8h | ✅ Sim |
| Exportar PDF do prontuário quebrava com acentos | P2 | 6h | ✅ Sim |
| Botão de “Cancelar consulta” mal alinhado no mobile | P3 | 30min | ✅ Sim |
Total de horas gastas em correções: 18,5h (zero custo para cliente)
Semana 3-4: ajustes de UX baseados em feedback
Médicos reportaram que interface de preenchimento de prontuário tinha muitos cliques desnecessários. Simplificamos fluxo:
- Antes: 7 cliques para salvar prescrição
- Depois: 3 cliques
Ajuste levou 4h. Coberto pela garantia (melhoria de usabilidade, não feature nova).
Semana 5-8: otimizações de performance
Com 180 pacientes usando, notamos lentidão no carregamento do histórico (3-5 segundos). Otimizamos query do banco. Carregamento caiu para 0,8s.
Tempo investido: 6h. Coberto pela garantia (correção de performance).
Semana 9-12: último ciclo de ajustes
- Ajuste de cores (pedido do cliente): 1h — coberto
- Correção de bug menor (data de nascimento aceitava ano 2050): 2h — coberto
- Adição de campo “Observações” no cadastro: 3h — coberto (campo simples, não mudou arquitetura)
Total de horas investidas na garantia: 34,5h (equivalente a R$ 6.900 se fosse cobrado — mas foi incluso).
Fase 2: Manutenção contínua (após 60 dias)
Cliente optou pelo Plano 2: Manutenção + Evolução (R$ 8K/mês)
Mês 3-6: features evolutivas
- Mês 3: Integração com laboratório para importação automática de exames (15h)
- Mês 4: Dashboard de métricas para gestão (agendamentos por médico, receita, cancelamentos) (12h)
- Mês 5: Prescrição digital com assinatura eletrônica (18h)
- Mês 6: Sistema de lembretes automáticos via WhatsApp (10h)
Total usado: 55h de 80h contratadas (20h/mês × 4 meses)
Resultado após 6 meses de operação:
| Métrica | Mês 1 | Mês 6 | Variação |
|---|---|---|---|
| Pacientes ativos | 180 | 520 | +189% |
| Consultas/mês | 380 | 1.240 | +226% |
| Receita mensal | R$ 68K | R$ 223K | +228% |
| Bugs reportados | 12 | 1-2/mês | -83% |
| Tempo de resolução médio | 4h | 1,5h | -62% |
| NPS | 58 | 78 | +34% |
ROI da manutenção contínua:
- Investimento: R$ 32K (4 meses × R$ 8K)
- Receita incremental gerada: R$ 620K (R$ 155K/mês × 4 meses de crescimento estabilizado)
- ROI: 1.837% (a manutenção permitiu escalar sem quebrar)
Arquitetura de suporte técnico (como garantimos SLA)
Stack de monitoramento e alertas
Sentry (error tracking):
- Captura 100% dos erros em produção
- Alerta instantâneo no Slack quando erro crítico acontece
- Custo: R$ 120/mês
Better Uptime (monitoramento de disponibilidade):
- Checa site a cada 30 segundos
- Alerta se ficar fora do ar por mais de 60 segundos
- Custo: R$ 60/mês
Linear (gestão de tickets):
- Cliente reporta bug via e-mail ou Slack
- Ticket criado automaticamente
- Priorização automática baseada em palavras-chave
- Custo: R$ 40/mês
Datadog (performance monitoring):
- Monitora latência de API, uso de memória, queries lentas
- Alerta se latência P95 > 2 segundos
- Custo: R$ 180/mês (apenas para projetos enterprise)
Total de custo de monitoramento: R$ 220-400/mês (incluso no plano de manutenção).
Processo de tratamento de bugs (da detecção à resolução)
Detecção automática:
- Erro acontece em produção → Sentry captura
- Se erro é crítico (P0) → Alerta no Slack em menos de 2 minutos
- Se erro é recorrente (mais de 10x em 1h) → Alerta mesmo que não seja crítico
Triagem manual:
- Desenvolvedor recebe alerta
- Classifica prioridade (P0/P1/P2/P3) em menos de 30 minutos
- Comunica ao cliente: “Identificamos o problema X, estimamos resolução em Y horas, te avisamos quando estiver resolvido”
Resolução:
- Fix desenvolvido
- Testado em staging
- Cliente valida em staging (apenas para P0/P1)
- Deploy em produção
- Monitoramento por 24h para confirmar que fix não gerou regressão
Fechamento:
- Cliente confirma que problema foi resolvido
- Post-mortem registrado (o que causou, como foi resolvido, como prevenir)
- Ticket fechado
Métricas de SLA (garantidas contratualmente)
| Prioridade | Descrição | Tempo de resposta | Tempo de resolução | Disponibilidade |
|---|---|---|---|---|
| P0 - Crítico | Sistema fora do ar, pagamentos não funcionam | menor que 2h | menor que 8h | 24/7 |
| P1 - Alto | Feature core quebrada (login, checkout) | menor que 8h | menor que 24h | Horário comercial estendido |
| P2 - Médio | Feature secundária com workaround | menor que 24h | menor que 72h | Horário comercial |
| P3 - Baixo | Cosmético, não bloqueia operação | menor que 48h | menor que 7 dias | Horário comercial |
Penalidades por descumprimento de SLA:
- P0 não resolvido em 8h: desconto de 20% na mensalidade do mês
- P0 recorrente (mais de 2x no mesmo mês): desconto de 50% na mensalidade
- Disponibilidade abaixo de 99,5% no mês: desconto proporcional
Histórico de cumprimento de SLA (últimos 12 meses):
- P0: 100% resolvidos dentro do SLA (média: 3,2h)
- P1: 97% dentro do SLA (2 casos excederam por bloqueio externo — API de terceiros)
- P2/P3: 100% dentro do SLA
7 erros fatais que clientes cometem com garantia e manutenção
1. Não reportar bugs pequenos durante a garantia
Erro: Cliente pensa “é só um detalhezinho, não vou incomodar”.
Resultado: Acumula 15 “detalhezinhos” que depois viram lista de ajustes fora da garantia (R$ 4.500 de custo que poderia ser zero).
Correto: Reporte tudo durante a garantia. Até detalhes pequenos. É melhor reportar demais do que de menos.
2. Pedir mudanças sem documentar
Erro: Cliente pede ajuste via WhatsApp informal (“ah, muda essa cor ali”). Depois esquece que pediu e reclama que mudou “sem autorização”.
Resultado: Conflito, retrabalho.
Correto: Todo pedido de ajuste vira ticket documentado. Cliente aprova formalmente antes de implementarmos.
3. Não testar em staging antes de aprovar deploy
Erro: Cliente aprova deploy direto em produção sem validar em ambiente de teste.
Resultado: Bug passa despercebido, afeta usuários reais.
Correto: Sempre testa em staging, valida que está ok, depois aprova deploy em produção.
4. Não investir em manutenção contínua (acha que produto “pronto” não precisa)
Erro: Cliente cancela manutenção após garantia, acha que produto está “finalizado”.
Resultado após 12 meses:
- Bibliotecas desatualizadas (vulnerabilidades de segurança)
- Dependências deprecated (sistema pode parar de funcionar)
- Bugs acumulados (pequenos problemas viram grandes)
Correto: Produto de software nunca está “pronto”. Precisa de manutenção contínua como carro precisa de revisão.
5. Usar todo o budget de manutenção em features (zero preventivo)
Erro: Cliente contrata 20h/mês mas usa tudo em features novas. Zero tempo para manutenção preventiva.
Resultado: Débito técnico acumula, performance degrada, bugs futuros mais caros de resolver.
Correto: Alocar 30-40% do budget para manutenção preventiva (atualização de dependências, refatoração, testes).
6. Esperar manutenção resolver problemas de negócio
Erro: Cliente acha que contratar manutenção vai fazer app “vender sozinho” ou “trazer mais clientes”.
Realidade: Manutenção mantém produto funcionando e evoluindo. Marketing e vendas trazem clientes.
Correto: Manutenção cuida do produto. Marketing cuida de tração. São investimentos complementares.
7. Não medir o impacto da manutenção
Erro: Cliente paga manutenção mas não acompanha métricas (bugs resolvidos, features lançadas, uptime).
Resultado: Não sabe se está tendo ROI.
Correto: Dashboard mensal com:
- Horas usadas vs contratadas
- Bugs resolvidos
- Features lançadas
- Uptime do mês
- Comparação com mês anterior
Investimento e ROI detalhado (quanto custa manter app no ar)
Cenário 1: Produto pequeno (menos de 500 usuários/mês)
Plano recomendado: Suporte Básico (R$ 3K/mês)
| Item | Custo mensal |
|---|---|
| Correção de bugs | Ilimitado (incluso) |
| Suporte técnico | Incluso (resposta menor que 48h) |
| 1 deploy/mês | Incluso |
| Atualizações de segurança | Incluso |
| Monitoramento (Sentry + Uptime) | R$ 220 (incluso) |
| TOTAL | R$ 3.000/mês |
Quando faz sentido:
- Produto maduro, poucas mudanças
- Bugs raros (menos de 3/mês)
- Não precisa de features novas
ROI típico:
- Custo de não ter manutenção: R$ 12-20K/ano em bugs acumulados, vulnerabilidades, downtime
- Custo de ter manutenção: R$ 36K/ano
- Economia vs reativo: R$ 0 (empata), mas evita riscos
Cenário 2: Produto em crescimento (500-2000 usuários/mês)
Plano recomendado: Manutenção + Evolução (R$ 8K/mês)
| Item | Custo mensal |
|---|---|
| Tudo do Plano Básico | Incluso |
| 20h/mês de desenvolvimento | Incluso |
| Deploys ilimitados | Incluso |
| Reunião mensal de roadmap | Incluso |
| Monitoramento avançado | R$ 400 (incluso) |
| TOTAL | R$ 8.000/mês |
20h/mês equivale a:
- 1-2 features médias/mês
- ou 3-4 features pequenas
- ou ajustes de UX + otimizações
Quando faz sentido:
- Produto em evolução, lançando features regularmente
- Feedback de usuários exige ajustes mensais
- Crescimento de uso exige otimizações
ROI típico:
- Custo de contratar dev interno: R$ 15-20K/mês (salário + encargos)
- Custo de manutenção externa: R$ 8K/mês
- Economia: R$ 84-144K/ano
Cenário 3: Produto enterprise (mais de 2000 usuários/mês)
Plano recomendado: Suporte Premium (R$ 15K/mês)
| Item | Custo mensal |
|---|---|
| Tudo do Plano Evolução | Incluso |
| 40h/mês de desenvolvimento | Incluso |
| SLA prioritário (P0 menor que 4h) | Incluso |
| Code review + pair programming | Incluso |
| Monitoramento enterprise | R$ 800 (incluso) |
| TOTAL | R$ 15.000/mês |
40h/mês equivale a:
- 2-3 features grandes/mês
- ou 4-6 features médias
- ou refatoração técnica significativa
Quando faz sentido:
- Produto crítico para operação (downtime custa caro)
- Time interno pequeno/inexistente
- Volume alto de usuários (bugs afetam muita gente)
ROI típico:
- Custo de contratar 2 devs internos: R$ 30-40K/mês
- Custo de manutenção premium: R$ 15K/mês
- Economia: R$ 180-300K/ano
Checklist: tudo que deve estar incluído na garantia (use ao contratar qualquer dev)
Durante o desenvolvimento
- Código-fonte entregue (você é dono, não o desenvolvedor)
- Documentação técnica (arquitetura, deploy, integrações)
- Credenciais de acesso (servidores, domínios, APIs)
- Testes automatizados (cobertura mínima de 60%)
- Ambiente de staging (para testar antes de produção)
Nos primeiros 60 dias (garantia)
- Correção de bugs ilimitada (P0/P1/P2/P3)
- Ajustes de UX pequenos (menos de 2h cada)
- Suporte técnico (resposta menor que 24h)
- 1 revisão de performance (otimização de queries lentas)
- Monitoramento de erros (Sentry ou similar)
- Backup automático configurado
- Documentação de usuário final (se aplicável)
O que NÃO deve estar incluído (para evitar conflito)
- Novas features (fora do escopo original do projeto)
- Integrações adicionais (além das especificadas no contrato)
- Mudanças de arquitetura (ex: migrar de SQL para NoSQL)
- Mudanças de design (redesign completo de telas)
- Suporte a novos dispositivos (ex: adicionar app Android se só tinha web)
Após 60 dias (manutenção contínua)
- SLA documentado (tempo de resposta e resolução por prioridade)
- Horas mensais contratadas (e o que acontece se não usar)
- Processo de renovação (automático ou manual?)
- Penalidades por descumprimento de SLA
- Processo de cancelamento (quanto tempo de aviso?)
Conclusão + próximos passos
Garantia de 60 dias não é “gentileza” — é necessidade técnica. Todo produto precisa de ajustes após o lançamento. Bugs aparecem com uso real. UX precisa de refinamento. Performance precisa de otimização.
Cliente que não exige garantia documentada está assumindo risco desnecessário: vai pagar por bugs que deveriam ser corrigidos gratuitamente.
Manutenção contínua não é opcional — é seguro contra obsolescência. Produto sem manutenção morre em 12-18 meses (dependências desatualizadas, bugs acumulados, vulnerabilidades de segurança).
ROI de manutenção bem feita:
- Produto escalável (aguenta crescimento sem quebrar)
- Usuários satisfeitos (bugs corrigidos rápido, features lançadas regularmente)
- Custo previsível (R$ 3-15K/mês vs surpresas de R$ 40K para resolver emergência)
Precisa de garantia real (não só promessa) e manutenção contínua?
Na OrientMe, garantia de 60 dias está documentada em contrato — não é marketing. SLA com penalidades. Código-fonte seu. Monitoramento 24/7.
Após 60 dias, manutenção contínua com horas mensais definidas, dashboard de métricas e reunião mensal de roadmap.
Agende diagnóstico gratuito para entendermos seu projeto e desenharmos proposta de desenvolvimento + garantia + manutenção com ROI documentado: