Como estamos construindo o FinSight AI: processo, pagamentos, segurança e lançamento
Um registro aberto do desenvolvimento do FinSight AI — engenharia, Pix e pagamentos, LGPD, segurança, infraestrutura e o plano de lançamento —, com um checklist para quem está começando uma empresa de software.
- Categoria
- Engenharia
- Autor
- Equipe Devx
- Leitura
- 8 min
Este é um registro aberto de como o FinSight AI está sendo construído: o processo de engenharia, como funcionam os pagamentos, o que fazemos em segurança e privacidade e como estamos preparando o lançamento. Escrevemos para quem está começando uma empresa de software e quer um mapa do que existe além do código — e também para mostrar, com transparência, como trabalhamos.
Uma ressalva antes de começar: documentamos práticas e processos, não configurações. Detalhes de infraestrutura, endereços internos, regras de proteção e limites exatos ficam de fora de propósito. Mais sobre isso no fim.
Onde o produto está hoje
O FinSight AI é um sistema de gestão financeira para pequenas e médias empresas, com IA. Ele está em pré-lançamento: os módulos principais estão prontos e em teste, algumas telas ainda podem mudar e o acesso começa por convite.
O que já funciona:
- Financeiro: lançamentos, contas a pagar e a receber, orçamento e metas.
- Visão do caixa: fluxo de caixa projetado com simulação "e se…", DRE mensal e relatórios em PDF e por e-mail.
- Cobrança: links de pagamento, Pix e boleto, com régua de lembretes por e-mail e WhatsApp.
- Banco e fiscal: conciliação por extrato (OFX) ou Open Finance e emissão de NFS-e.
- IA: um CFO Virtual que analisa os números e um Copiloto que executa tarefas — sempre com confirmação.
- Integrações: API pública, webhooks e servidor MCP para conectar outras ferramentas e assistentes de IA.
- Equipe: várias pessoas por empresa, com funções e permissões, e interface em português e inglês.
O que ainda está na fila: funções personalizadas por empresa, monitoramento de erros mais completo e testes de ponta a ponta de todos os meios de pagamento em produção.
Como trabalhamos
Testes antes de cada entrega
Cada mudança passa por checagem de tipos e por uma suíte de testes automatizados que hoje tem perto de mil testes. Eles cobrem desde contas e relatórios até os pontos que mais importam num produto financeiro: isolamento entre empresas (uma empresa nunca vê dados de outra), pagamentos que não podem ser contados duas vezes e as regras de privacidade.
A IA tem baterias próprias: uma que verifica se o Copiloto escolhe a ação certa para cada pedido e outra que roda conversas reais de ponta a ponta.
Do código à produção
- Integração contínua: checagem de tipos, testes, build e uma varredura que procura segredos esquecidos no código que vai para o navegador.
- Dois ambientes: homologação, para validar, e produção, para os clientes.
- Versões numeradas: só uma versão marcada (v1.2.3) vai para produção, com verificação de saúde depois do deploy e notas de versão.
- Configuração que se defende: o servidor se recusa a subir em produção se alguma configuração crítica estiver fraca ou faltando.
- Ambiente local completo: banco de dados local e uma empresa de demonstração com mais de um ano de dados fictícios, para testar sem tocar em dados reais.
Agentes de IA como parte do time
Usamos agentes de IA para acelerar o desenvolvimento, vários ao mesmo tempo, cada um em uma cópia isolada do código. O que eles escrevem passa pelos mesmos testes, pela mesma revisão e pelo mesmo processo de versão que qualquer outra mudança.
O que é o Pix, em poucas palavras
O Pix é o sistema de pagamentos instantâneos criado pelo Banco Central do Brasil. O dinheiro chega em segundos, a qualquer hora, todos os dias, e o pagador só precisa de uma chave (CPF, CNPJ, e-mail, telefone ou chave aleatória) ou de um QR Code — que também vem em versão "copia e cola".
O Pix Automático é a versão recorrente: o cliente autoriza uma vez no app do banco e as cobranças seguintes (mensalidade, assinatura) são debitadas sozinhas, sem precisar pagar um Pix por mês. Para negócios de assinatura, isso reduz atraso e esquecimento.
Como funcionam os pagamentos no FinSight
Existem dois fluxos, e separá-los foi uma das primeiras decisões.
1. A plataforma cobrando quem assina o FinSight. Planos com cartão recorrente, Pix Automático e pacotes avulsos de créditos de IA, processados por provedores de pagamento regulados.
2. As empresas cobrando os clientes delas. Cada empresa conecta a conta que ela mesma contrata em um provedor de pagamento (há várias opções) e cobra por link, Pix ou boleto. O FinSight nunca segura o dinheiro: o valor cai direto na conta da empresa. Isso simplifica a regulação e reduz o risco para todo mundo.
O ciclo de uma cobrança:
- A cobrança é criada e enviada ao cliente.
- Quando o pagamento acontece, o provedor avisa o sistema.
- O sistema não confia só no aviso: consulta o provedor de novo para confirmar o status real.
- A baixa é feita de forma idempotente — o mesmo pagamento nunca é contado duas vezes, mesmo que o aviso chegue repetido.
- A receita entra no financeiro já conciliada e a nota fiscal de serviço pode ser emitida automaticamente.
Como rede de segurança, o sistema também verifica periodicamente as cobranças pendentes, para o caso de algum aviso se perder no caminho. A conciliação bancária completa o círculo: o extrato chega por Open Finance ou por arquivo OFX e é comparado com o que foi lançado.
IA com freio de mão
- O CFO Virtual analisa os números na frequência que a empresa escolher e gera alertas, diagnóstico e plano de ação — usando métricas agregadas.
- O Copiloto responde perguntas e executa tarefas: lançar uma despesa, criar uma cobrança, gerar um relatório.
As regras que tornam isso seguro:
- Consultar é imediato; alterar exige confirmação. Toda ação que muda dados vira uma proposta editável, com "Confirmar" ou "Descartar".
- As permissões são checadas de novo na confirmação. A IA não dá acesso a nada que a pessoa não teria sozinha.
- O que a IA escreve é tratado como dado, nunca como autorização.
- Dados pessoais são mascarados (CPF, CNPJ, e-mail, telefone, cartão) antes de qualquer texto ir para o modelo.
- Uso por créditos, com devolução automática quando uma chamada falha.
Jurídico e LGPD
Para quem está começando, esta foi a parte com mais itens que não aparecem no código:
- Empresa formalizada (no nosso caso, LTDA no Simples Nacional), com contador desde o início e atenção às regras da nota fiscal de serviço.
- Marca: registro no INPI no planejamento.
- Termos de Uso e Política de Privacidade públicos, escritos com base na LGPD, no Código de Defesa do Consumidor, no decreto do comércio eletrônico e no Marco Civil da Internet.
- Aceite com prova: o aceite fica registrado com versão e data. Se o texto muda, a versão sobe e todos aceitam de novo.
- Papéis claros: a empresa cliente é a controladora dos dados que insere; a plataforma atua como operadora.
- Direitos do titular dentro do produto: exportar todos os dados e excluir a conta direto no app, com canal do encarregado (DPO) e prazo de resposta.
- Retenção definida: cada tipo de dado tem prazo, e backups são sobrescritos em ciclos.
- Cookies: só o essencial por padrão; análise de uso apenas com consentimento.
Ainda no checklist: revisão jurídica final, contrato de tratamento de dados (DPA), registro das operações de tratamento e plano formal de resposta a incidentes.
Segurança
O que fazemos, em termos gerais:
- Conexões sempre por HTTPS e senhas guardadas com hash forte.
- Chaves de API armazenadas só como hash e credenciais de integração criptografadas.
- Isolamento entre empresas testado automaticamente e controle de acesso por funções.
- Limite de tentativas e bloqueio após falhas repetidas.
- Assinatura verificada nos avisos dos provedores de pagamento.
- Cabeçalhos de segurança no navegador.
- Trilha de auditoria, com logs que não guardam dados sensíveis.
- Verificação em duas etapas obrigatória nas áreas administrativas.
- Backups diários com teste de restauração e cópia fora do servidor.
- Proteção de borda com a Cloudflare (DNS, HTTPS, firewall de aplicação e mitigação de ataques).
Uma lição que vale registrar: um serviço de borda sozinho não é suficiente. Ele é uma camada. A segurança de verdade está em várias camadas ao mesmo tempo — na borda, no servidor, no banco e no próprio código.
Infraestrutura, do zero
O mínimo para colocar um SaaS no ar com responsabilidade:
- Domínio e DNS com proteção de borda (usamos a Cloudflare).
- HTTPS em tudo, renovado automaticamente.
- Servidor com deploy automatizado e versionado — nada de alterações manuais em produção.
- Banco de dados gerenciado, com backups diários testados.
- E-mail profissional com SPF, DKIM e DMARC configurados, para que as mensagens não caiam no spam.
- E-mail transacional separado para cadastro, cobrança e avisos.
- Monitoramento do serviço e uma página de status pública.
O lançamento
Já está pronto:
- Página do produto e página de preços com plano gratuito.
- SEO básico: sitemap, robots.txt, Search Console e áreas privadas fora da busca.
- Análise de uso com consentimento e acompanhamento de cadastros e compras.
- Lista de acesso antecipado.
- Convites por e-mail com link de uso único e descadastro, começando por escritórios de contabilidade — que atendem muitas pequenas empresas.
- Programa de indicação: o contador repassa um cupom aos clientes.
- Códigos promocionais (meses grátis e créditos de IA).
- Página de status e comunidade.
Preparado, ainda não publicado:
- Google Ads: temas de pesquisa e palavras negativas já mapeados.
- Redes sociais: posts, imagens e vídeo de lançamento prontos.
Próximos passos:
- Teste de ponta a ponta com uma empresa real antes da abertura geral.
- Product Hunt e outros canais de lançamento em avaliação.
- Canal de suporte definido.
- Métricas de receita recorrente (MRR) e cancelamento (churn) desde o primeiro cliente.
Checklist para quem está começando
- Empresa: CNPJ, contador, enquadramento tributário, nota fiscal de serviço, marca no INPI.
- Jurídico: termos, privacidade, aceite registrado e versionado, papéis da LGPD, canal do encarregado, prazos de retenção.
- Engenharia: testes automatizados, integração contínua, homologação separada de produção, versões numeradas, configuração que se recusa a subir insegura.
- Pagamentos: provedor regulado, avisos verificados, baixa idempotente, verificação periódica, conciliação bancária.
- Segurança: camadas (borda, servidor, banco, código), 2FA nas áreas administrativas, backups testados, logs sem dados sensíveis.
- Infraestrutura: domínio, DNS, HTTPS, e-mail com SPF/DKIM/DMARC, monitoramento, página de status.
- Lançamento: landing page, preços claros, SEO, lista de espera, convites, indicação, canais pagos com termos já pesquisados.
O que não publicamos (e por quê)
Contar como trabalhamos não pode facilitar a vida de quem quer atacar. Por isso este texto não traz endereços internos, nomes de servidores, regras de firewall, limites exatos, fornecedores de infraestrutura além do que já é público, nem nomes ou contatos de pessoas da equipe. Nenhum atendimento da Devx pede senha, código de verificação ou acesso remoto — se alguém pedir em nosso nome, não é a gente.
Tem perguntas sobre algum desses processos? Fale com a gente pela página de contato.
- #finsight ai
- #processo
- #pagamentos
- #pix
- #lgpd
- #segurança
- #lançamento