Este material foi preparado exclusivamente para o André.
Insira a senha para acessar.
André, lemos o escopo da plataforma da corretora com atenção e queremos devolver algo antes de qualquer número.
Este documento não é uma proposta. É um gesto. Um mapa dos pontos que, na nossa experiência construindo plataformas parecidas, definem se o projeto vai bem ou vai doer — e que identificamos na leitura do material que o Lucca nos enviou.
André, o escopo que recebemos de vocês é muito bom — com honestidade, está acima da média do que chega até a gente. Tem estrutura, tem matriz de permissões, tem fluxo de tíquete desenhado, tem cuidado com LGPD. Isso é raro, e diz muito sobre como vocês pensam a operação.
Justamente por ser bom, decidimos não responder com um orçamento na semana seguinte. Projetos como o de vocês — multi-tenant, dados sensíveis de saúde, três públicos distintos usando o mesmo sistema — têm um padrão conhecido: o que não foi decidido no início vira o custo, o prazo e o atrito do final.
Uma leitura técnica com 15 pontos que identificamos no escopo. Cada um é uma pergunta que, respondida agora, evita retrabalho depois. Divididos em três níveis: crítico (afeta arquitetura e margem), de negócio (afeta escopo e expectativa) e técnico/UX (afeta adoção e compliance).
Você pode usar esse documento do jeito que quiser. Levar pra equipe interna. Levar pra outra empresa. Discutir com o Lucca. Engavetar. Nenhum desses caminhos nos ofende. A gente acredita que parceria de software começa antes da assinatura — e que entregar valor sem cobrar é a forma mais honesta de mostrar como trabalhamos.
Boa leitura.
Estes são os gaps que, se decididos só depois do projeto começar, tipicamente dobram o custo ou quebram o prazo. Não porque alguém errou — mas porque mudam a fundação, e fundação só se muda demolindo.
O documento não menciona quantas empresas a corretora atende hoje, quantos colaboradores estão na base, quantos tíquetes são abertos por mês, quantos usuários acessam simultaneamente. Mesmo escopo funcional pode significar 3x de diferença no custo de infraestrutura, banco e arquitetura.
O escopo menciona "entrada manual de sinistralidade quando não houver integração direta". Na prática, isso significa que a integração vai existir — mas não sabemos com quais operadoras. Bradesco, SulAmérica, Amil, Unimed, Odontoprev? Cada uma opera de forma diferente: algumas têm API, outras arquivo TISS, outras exigem portal scraping.
Esta é a diferença entre um MVP de 6 meses e um projeto de 18 meses. Não dá pra precificar com honestidade sem mapear.
O escopo descreve o sistema novo, mas não menciona o que existe hoje. Planilhas? Sistema atual? Quantos anos de histórico? Quantos colaboradores ativos para migrar no dia 1? Migração em corretora de seguros envolve dados sensíveis de saúde, conciliação com a operadora e LGPD — é um projeto dentro do projeto.
No painel do colaborador, existe a função de "adquirir produtos extras". Mas o escopo não fala em pagamento, contrato digital, assinatura eletrônica nem efetivação junto à operadora. Isso pode ser uma coisa de duas:
Ou é um tíquete de solicitação — e aí o nome deveria ser "solicitar", não "adquirir" — ou é um módulo completo de checkout, contratação e integração, que por si só é quase metade de outro projeto.
Estes não quebram o projeto, mas são as portas por onde o escopo aberto entra. Decididos antes, viram requisito claro. Decididos durante, viram "só mais uma feature" em cada reunião semanal.
"Sinistralidade acima de 75% dispara alerta" é um exemplo, não é a regra de vocês. Qual é a fórmula real? Cada operadora calcula diferente, cada contrato tem cláusula própria, e existem IPCA, VCMH, franquia, coparticipação. Isso é um motor de regras de negócio — precisa ser mapeado em workshop com o time comercial da corretora, não em e-mail.
O SLA é configurável, mas configurável por quem? Por empresa contratante? Por tipo de demanda? Por plano? Existe escalonamento quando estoura? Horário comercial conta ou é 24/7? Feriado entra? Sem definir, cada tipo de demanda vira uma exceção na régua de cobrança.
O documento lista cinco tipos de demanda e fecha com "entre outros configuráveis". Cada tipo, na prática, tem formulário próprio, documentos obrigatórios próprios, SLA próprio e fluxo próprio. Quantos tipos entram no MVP? Quem é o responsável por criar novos tipos depois?
A tabela do escopo cobre "Corretora x Empresa", mas os três perfis internos da corretora (Administrador, Operador, Consultor) não têm granularidade descrita. O Consultor pode ver o prontuário do colaborador? O Operador pode excluir uma empresa inteira? Isso precisa estar decidido antes de escrever a primeira linha de código — depois vira bug de segurança.
Sistema bem desenhado tecnicamente e mal adotado pelos usuários é um projeto fracassado com aparência de sucesso. Essas três perguntas definem adoção.
O escopo descreve o que o colaborador faz na tela, mas não quem ele é. Idade média, nível de familiaridade com tecnologia, dispositivo principal de acesso. Um painel de colaborador para uma construtora no interior e para uma empresa de tecnologia em São Paulo não é o mesmo produto — nem deveria ser.
O escopo diz o que o RH pode fazer, mas não como ele trabalha hoje. Quantas pessoas no RH de cada empresa-cliente? Eles já usam Gupy, Senior, TOTVS? Precisa de integração via SSO? A resposta define se o sistema vai ser usado todos os dias ou vai ser ignorado em favor da planilha antiga.
Colaborador e empresa consultam a rede credenciada dentro do sistema. Mas quem mantém essa base atualizada? A corretora digita manualmente? Vem da operadora por arquivo ou API? Se for manual, vai desatualizar em três meses. Se for integração, volta a depender do GAP 02.
O escopo menciona LGPD em uma linha. Dado de saúde é categoria especial pela lei — exige tratamento separado, base legal específica e parecer jurídico. Não é checkbox.
Dados de saúde são dados sensíveis pelo artigo 5º da LGPD. Exigem base legal específica, DPO designado, Relatório de Impacto (RIPD) e anonimização em logs. Um sistema que armazena prontuário precisa passar por esse crivo antes de ir pro ar — não depois. A multa por vazamento é de até 2% do faturamento.
O escopo fala em "histórico médico relevante" num campo livre acessado pela corretora. Isto é, operacionalmente, um prontuário. Quem autorizou o tratamento desses dados? Qual a base legal? Onde fica o termo de consentimento do colaborador? Esse ponto isolado pode exigir um parecer jurídico antes de qualquer linha de código.
"Arquitetura preparada para WhatsApp" é frase bonita que, sem decisão de hoje, vira retrabalho amanhã. API oficial (Cloud API, com custo por mensagem e aprovação de template) ou biblioteca não-oficial (mais barato, risco de ban)? Quem paga a conta da Meta? Qual o volume esperado? A camada de notificação muda inteira dependendo da resposta.
O escopo não menciona tempo de resposta esperado, uptime desejado, RPO/RTO (quanto dado pode ser perdido e em quanto tempo precisa voltar em caso de desastre), retenção de logs nem performance de relatórios com anos acumulados. Tudo isso vira reclamação do cliente na fase de aceite, quando já é tarde.
Nenhum desses 15 pontos é impeditivo. Nenhum é crítica ao trabalho do Lucca — pelo contrário, o escopo dele já resolveu boa parte do que normalmente chega bagunçado. Estes são os pontos que o escopo sozinho não tinha como resolver, porque dependem de decisões de negócio, conversas com usuários reais e parecer jurídico.
O projeto é de complexidade média-alta, mas muito bem delimitada. Não é foguete. É um ERP vertical de nicho, com três elementos que aumentam o peso: multi-tenant em três níveis, dados sensíveis de saúde e um motor de regras de sinistralidade.
Para um MVP enxuto dos três painéis, com tíquetes, sinistralidade básica e imports por Excel — sem integração direta com operadora no primeiro release — estamos falando em um time pequeno e um prazo entre seis e nove meses. Esses 15 pontos, respondidos antes do início, podem representar uma diferença de mais de R$ 80 mil na estimativa final. Para mais ou para menos.
Escopo bom é o que sobrevive ao contato com a realidade. O seu já está a meio caminho — esses 15 pontos são o resto do caminho.
André, como dissemos no começo — esse documento é um gesto, não uma proposta. Tem dois caminhos naturais daqui:
Não esperamos resposta imediata. A ideia é exatamente essa — que você tenha tempo de ler, discutir e decidir com calma. Quando fizer sentido, a Natália Muzzi, nossa Diretora Comercial, está à disposição pra conversar sobre qualquer um dos dois caminhos — ou nenhum dos dois.
Ler um projeto como o de vocês é, pra nós, também uma forma de aprender. Esperamos que esse material tenha valor, independente do que acontecer daqui em diante.
— Hélio Biancardi
CTO · BianCode