Publicado em 15 de março de 2026
Por aproximadamente três anos e meio, trabalhei como desenvolvedor full-stack na Activesoft Consultoria, contribuindo para o desenvolvimento e manutenção do Sigaweb (SIGA) — um sistema de gestão educacional de grande escala utilizado por escolas e universidades. O sistema abrange desde a matrícula de alunos e registros acadêmicos até a cobrança financeira e relatórios institucionais.
Na época da minha saída em agosto de 2024, a plataforma atendia mais de 700 escolas em todo o Brasil, impactando mais de 1 milhão de usuários. A Activesoft, fundada em 2002, havia se integrado ao Grupo Arco em 2023, tornando-se o sistema oficial de gestão escolar do maior grupo de educação básica da América Latina.
Ao longo desse período, contribuí com cerca de 2.765 commits em 810 dias de trabalho, modificando mais de 1.600 arquivos únicos em mais de 10 módulos principais da aplicação. Minhas contribuições adicionaram mais de 123.000 linhas de código, com uma contribuição líquida de aproximadamente +85.000 linhas.
Commits
Cards de features entregues
Linhas de código (líquido)
Arquivos modificados
Pull requests mergeados
Frontend (1.304 arquivos): React 16, TypeScript (strict mode), Styled-components, Redux, Formik, Webpack, Storybook
Backend (236 arquivos): Python, Django, Django REST Framework, Microsoft SQL Server
Infraestrutura e Ferramentas: Docker, AWS, Cypress, Git, pipelines de CI/CD
Meu envolvimento com o projeto foi consistente ao longo dos anos. Passei de aprender um codebase grande e desconhecido a entregar de forma autônoma features complexas em múltiplos módulos:
Trabalhar em um sistema dessa escala trouxe desafios que iam além de escrever código para features individuais:
A parte voltada ao usuário da aplicação foi construída com React utilizando componentes funcionais e hooks. Utilizei padrões como hooks customizados para encapsular lógica reutilizável (por exemplo, um hook de seleção que gerencia alternância, seleção parcial e estados desabilitados em listas), e composição de componentes para construir interfaces complexas a partir de peças menores e focadas, ao invés de depender de herança.
Formulários — centrais em um sistema de gestão — foram tratados com Formik combinado com Yup para validação baseada em schemas. Isso permitiu construir formulários multi-etapas com visibilidade condicional de campos, validação assíncrona (como consulta de CEP), e regras de validação aninhadas, tudo mantendo a lógica de validação separada do código da interface.
A estilização seguiu uma abordagem CSS-in-JS com Styled-components, integrada a um design system que fornecia tokens de tema (cores, fontes, espaçamentos) para consistência visual. Os componentes suportavam sistemas de variantes (por exemplo, botões com variantes primária, secundária, perigo e link) e comportamento responsivo através de hooks de detecção de tamanho de tela.
Todo o código foi escrito em TypeScript com modo estrito habilitado, utilizando interfaces para props de componentes, enums para constantes de domínio e generics em utilitários reutilizáveis. Essa rigidez ajudou a capturar erros em tempo de compilação ao invés de em produção.
O backend era baseado em Django e Django REST Framework, onde trabalhei com serializers para transformar dados entre o banco de dados e a API, e com views baseadas em classes organizadas através de mixins — blocos de construção reutilizáveis que adicionam capacidades específicas (como versionamento ou controle de acesso) a endpoints de API sem duplicação de código.
Para consultas financeiras e relatórios complexos, escrevi SQL parametrizado com segmentos de consulta dinâmicos que se adaptavam com base na versão do sistema e nas permissões do usuário. Essa abordagem permitia que o mesmo endpoint de relatório atendesse diferentes instituições com diferentes conjuntos de funcionalidades, mantendo as consultas protegidas contra ataques de injeção.
O controle de acesso era aplicado no nível da API através de um sistema de permissões que verificava se a instituição do usuário tinha uma determinada funcionalidade habilitada antes de permitir operações, garantindo que dados financeiros fossem acessíveis apenas a usuários autorizados.
A comunicação entre frontend e backend passava por uma camada de classes de cliente API construídas sobre o Axios. Cada cliente era responsável por um único domínio (como cobrança ou formas de recebimento) e cuidava da transformação de dados entre as convenções de nomenclatura do backend e do frontend, incluindo conversões de formato de data e mapeamento de campos para entidades com dezenas de atributos.
Para operações com arquivos, como upload de arquivos de retorno para processamento de pagamentos, utilizei uploads baseados em FormData com metadados anexados. Selects assíncronos com paginação e cache também faziam parte dos padrões de integração que utilizei frequentemente, permitindo que usuários pesquisassem grandes conjuntos de dados sem carregar tudo de uma vez.
Minha principal área de especialização foi o módulo financeiro, onde entreguei 77 cards de features. No frontend, isso significou construir formulários complexos para configuração de faturas, processamento de recebíveis e gestão de condições de pagamento — formulários que frequentemente abrangiam múltiplas abas, tinham campos condicionais e exigiam validação inline contra regras de negócio. No backend, implementei serializers para estruturas de dados financeiros, views de relatórios com filtros configuráveis e endpoints de operações em lote para geração de impostos e modificações de títulos.
Também participei da integração de pagamentos via Pix, contribuindo com implementações de APIs, a tela de listagem de recebimentos, um modal para vinculação de serviços a Pix imediato, o componente de recebimento por transferência/Pix, o redesign do formulário de cadastro da forma de recebimento Pix e a funcionalidade de boleto Pix com geração de QR code.
Fui um contribuidor significativo do sistema de comunicação multicanal da instituição (SMS, e-mail e notificações no aplicativo), responsável por 30% dos commits do componente. Minhas contribuições incluíram melhorias no fluxo do modal multi-etapas (construído como uma composição de componentes de etapas que compartilham estado através do contexto do Formik), gestão de modelos de texto personalizados com funcionalidades de salvar e editar, funcionalidade de envio de mensagens de teste para pré-visualização antes do envio, correções no contador de mensagens e diversos ajustes de UX solicitados durante revisões de código.
Entreguei 14 cards de features no lado acadêmico e de treinamento do sistema, incluindo geração de históricos escolares para diferentes tipos de escola, atas de resultados finais, funcionalidades do portal do aluno com fichas médicas, configurações de relatórios personalizados por instituição de ensino e funcionalidades do módulo de treinamento para desenvolvimento de funcionários.
Trabalhei em 5 cards de features para o módulo de CRM, implementando funcionalidades de parceria e gestão de relacionamento com clientes para o fluxo de vendas institucional.
O projeto seguia um fluxo estruturado com revisões de pull request, documentação abrangente de changelog e pipelines de CI/CD. Componentes eram documentados no Storybook para referência visual, e testes de ponta a ponta eram escritos com Cypress. O codebase era organizado em uma arquitetura baseada em features com separação clara de camadas: componentes de design system, componentes de UI, lógica de negócio específica de domínio e classes de cliente API.
O projeto contou com 57 contribuidores e mais de 1.000 releases durante meu tempo na equipe, refletindo uma cadência de entrega acelerada e bem organizada.