De ferramenta interna a SaaS: automação do download de extratos bancários
Construímos um script para baixar automaticamente nossos extratos bancários do Wise. Essa é uma tarefa de uma tarde. A questão mais interessante — que levou consideravelmente mais tempo para ser respondida — foi se a mesma ferramenta poderia atender outros negócios com o mesmo problema e o que seria necessário para fazer essa transição de forma responsável. A jornada de um script CLI executado no laptop de um desenvolvedor para um serviço executado em contêiner com notificações por e-mail expôs um conjunto de decisões que vale a pena documentar, particularmente para equipes avaliando se uma automação interna vale a pena ser transformada em produto.
O problema original
O Wise fornece uma API para acessar dados de conta, mas o fluxo de trabalho padrão para a maioria das equipes financeiras é fazer login na interface web e baixar manualmente um extrato em CSV no final de cada mês. Para uma única conta com uma única moeda, isso leva dois minutos. Para operações que trabalham com múltiplas moedas em múltiplas contas Wise — um padrão comum para empresas com fluxos de pagamento regionais — isso se torna uma sobrecarga recorrente que alguém precisa lembrar, executar de forma consistente e arquivar corretamente.
A API do Wise expõe os endpoints necessários. Você pode recuperar uma lista de perfis, obter saldos por moeda e solicitar exportações de extratos em formato CSV ou PDF para qualquer intervalo de datas. A autenticação é feita através de um token de acesso pessoal que você gera no painel de desenvolvedor do Wise. O token tem acesso somente leitura aos dados da conta quando seu escopo é definido corretamente, o que significa que pode ser armazenado e usado sem o perfil de risco de um token que poderia iniciar transferências.
Nossa primeira implementação tinha cerca de 80 linhas de Python. Ela lia credenciais de variáveis de ambiente, iterava sobre perfis e saldos de moeda, construía solicitações de extratos para o mês anterior e gravava os arquivos de saída em um diretório local. Ela era executada manualmente. Isso era suficiente para nossas necessidades na época.
De script para serviço agendado
O passo de “é executado manualmente” para “é executado automaticamente” introduz uma classe diferente de preocupações. Um script que falha silenciosamente quando executado manualmente é percebido imediatamente. Um script agendado que falha silenciosamente no primeiro dia de cada mês pode passar despercebido por vários meses, deixando uma lacuna no seu arquivo de extratos que você descobre durante uma auditoria.
Movemos o script para um contêiner Docker com um entrypoint simples e adicionamos um wrapper que envia uma notificação por e-mail na conclusão — sucesso ou falha. O e-mail inclui um resumo de quais contas e moedas foram processadas, quantos arquivos foram baixados e os tamanhos dos arquivos. Em caso de falha, inclui a saída de erro. Esse é um investimento mínimo em observabilidade, mas muda o contrato operacional: a automação agora é supervisionada, mesmo que seja executada sem intervenção manual.
O agendamento é feito pelo GitHub Actions, não por cron dentro do contêiner. Usamos um gatilho schedule em um fluxo de trabalho que é executado no início de cada mês; um agendamento cron por si só não permite selecionar dias úteis, então, para pular fins de semana e feriados, é necessária uma verificação adicional da data no fluxo de trabalho. O fluxo de trabalho faz checkout do repositório, constrói a imagem Docker se ela tiver mudado, executa o contêiner com segredos injetados do GitHub Secrets e faz upload dos arquivos de saída como artefatos de fluxo de trabalho. Os artefatos são mantidos por 90 dias, fornecendo um acervo recuperável independente de qualquer armazenamento de arquivos local.
A abordagem do GitHub Actions tem uma vantagem prática sobre um cron job em um servidor: ela é visível. O histórico de execuções do fluxo de trabalho mostra cada execução, sua duração, seu código de saída e os artefatos que produziu. Um cron job em um servidor produz saída de log que é fácil de perder e depende da disponibilidade do servidor. Para uma tarefa mensal, ter um histórico de execução auditável em uma definição de fluxo de trabalho com controle de versão vale a pequena sobrecarga da configuração do fluxo de trabalho.
O que “Multi-Tenant” realmente requer
Depois que a versão em contêiner tinha funcionado de forma confiável por vários meses, colegas de outros negócios perguntaram se poderiam usá-la. A pergunta parece simples: outras pessoas podem usar sua ferramenta? Mas, na prática, “outras pessoas usam sua ferramenta” abrange uma ampla gama de modelos operacionais com implicações muito diferentes.
O modelo mais simples: você compartilha o repositório e a documentação, outros executam por conta própria em seu próprio GitHub Actions ou ambiente Docker, e você não fornece suporte. Isso é distribuição de código aberto. Não é um produto SaaS. O ônus operacional é inteiramente do usuário.
O próximo passo: você hospeda a ferramenta e os usuários fornecem seus próprios tokens de API do Wise por meio de uma interface de configuração. Agora você mantém credenciais. Isso cria imediatamente obrigações de segurança e conformidade que são qualitativamente diferentes de executar uma automação pessoal. Você deve responder: como as credenciais são armazenadas, quem tem acesso a elas, o que acontece se o armazenamento for comprometido e qual é sua responsabilidade se a conta Wise de um usuário for acessada através da sua plataforma?
O passo seguinte envolve cobrança, suporte, compromissos de nível de serviço e a sobrecarga operacional de executar infraestrutura para múltiplos usuários. Nenhum desses é intransponível, mas cada um requer uma decisão sobre quanto investimento de engenharia você está preparado para fazer e qual custo operacional recorrente você está disposto a assumir.
A avaliação do SaaS
Fizemos a avaliação listando os requisitos para uma versão multi-tenant mínima e estimando o custo de cada um com franqueza. O gerenciamento de credenciais sozinho — armazenar tokens de API do Wise com segurança, fornecer uma interface para gerenciá-los e implementar os controles de acesso para impedir o acesso aos dados de outros clientes — é uma semana de trabalho de engenharia antes de você tocar na funcionalidade real de download de extratos. Adicione autenticação de usuário, cobrança, um serviço de entrega de e-mail com opção de cancelar o recebimento de e-mails e monitoramento de falhas de tarefas por cliente, e você tem um produto que requer investimento sustentado para manter com segurança.
O mercado para essa ferramenta específica também é limitado. Empresas grandes o suficiente para se preocupar em automatizar downloads de extratos geralmente são grandes o suficiente para ter software de contabilidade que se integra diretamente com o Wise, ou equipes financeiras que já resolveram o problema por seus próprios meios. O mercado potencial está na faixa intermediária — empresas grandes o suficiente para sentir a dor, mas que ainda não usam sistemas de contabilidade integrados.
Concluímos que a ferramenta não era uma boa candidata a SaaS para nossa equipe no estágio atual. O potencial de receita não justificava o investimento em engenharia e operação. O modelo de distribuição de código aberto atende à necessidade real sem criar obrigações que não conseguimos sustentar.
O que mantivemos e o que mudamos
A ferramenta interna ainda está em execução. A estendemos ao longo do tempo para gerar saída em PDF além de CSV, para enviar arquivos de extratos diretamente para um endereço de e-mail em vez de depender da recuperação de artefatos de fluxo de trabalho, e para aceitar intervalos de datas configuráveis para que possa ser acionada manualmente para solicitações pontuais de extratos sem alterar a execução mensal agendada.
O fluxo de trabalho do GitHub Actions se tornou o mecanismo de implantação canônico. Documentamos no README do repositório com detalhes suficientes para que alguém que não tocou na ferramenta em seis meses possa entender o que ela faz e como operá-la. Essa é uma disciplina que vale a pena aplicar a qualquer automação interna: trate suas ferramentas internas como se você precisasse entregá-las a outra pessoa, porque eventualmente você precisará.
A lição mais duradoura deste projeto é sobre a lacuna entre “isso funciona para nós” e “isso funciona para outros.” As ferramentas internas são ajustadas às suas restrições específicas: suas práticas de gerenciamento de credenciais, suas convenções de armazenamento de arquivos, sua infraestrutura de e-mail. Torná-las genéricas o suficiente para outros usarem não é apenas uma questão de adicionar um arquivo de configuração. Requer abstrair suposições que você não sabia serem suposições até que outra pessoa tentou usar a ferramenta e as encontrou.