01
Software sob medida
Sistemas construídos a partir da regra real do negócio, não adaptados de um modelo pronto. É o que os quatro casos abaixo comprovam.
Ver os casosFontes Mídias — software sob medida
Entender o processo antes de propor o sistema.
Software de prateleira não conhece a regra do seu negócio. Quando ele não chega, aparece a planilha paralela, o documento por WhatsApp e a assinatura à caneta.
- Sistemas em produção
- 4
- Anos resolvendo folha, admissão e escala
- 3
- Setores atendidos: RH, folha, escala e benefícios
- 4
01O problema
O sistema genérico não sabe por que a sua regra existe.
Quem trabalha com terceirização, folha ou escala convive com regras que nasceram de contrato, de lei ou de uma negociação específica. O software de mercado não tem como conhecê-las — e onde ele não chega, alguém compensa no braço.
A
O formulário de 50 perguntas
Um RH admitia pessoas com um formulário que não podia ser salvo pela metade. Documento por WhatsApp, ficha impressa, assinatura à caneta, dossiê montado à mão.
Semanas por admissão
B
Férias que descobrem o posto
Aprovar férias sem planejar quem cobre o posto quebra contrato com o cliente. Adiar demais gera multa. Ninguém conseguia responder quantos substitutos seriam necessários no mês seguinte.
Risco contratual e trabalhista · CLT, art. 137
C
Recibo a recibo, todo mês
O Departamento Pessoal copiava valores de vale-alimentação de uma planilha para um modelo de documento, um colaborador por vez. O trabalho crescia junto com a folha.
Trabalho proporcional ao quadro
02Serviços
Quatro frentes. Todas começam pela mesma pergunta.
Qual é o processo hoje, e por que ele é assim? A resposta é o que define se o caminho é um sistema novo, uma automação, um modelo de linguagem ou apenas manter de pé o que já funciona.
02
Automação de processos
Integrações entre o que já existe, disparo por e-mail e WhatsApp, rotina manual que vira rotina automática. Sem trocar as ferramentas que a equipe domina.
03
IA com conformidade
Modelo de linguagem aplicado onde ele ajuda, com anonimização antes do envio, decisão registrada e barreira contra resposta inventada.
LGPD
04
Sustentação e evolução
Manutenção de sistema já em operação, seu ou herdado de outro fornecedor. O projeto não termina na entrega.
03Cases
Quatro sistemas em produção. Problema, decisão, resultado.
O que aparece abaixo não é lista de funcionalidade — é o raciocínio que levou a cada escolha. Os quatro sistemas estão em operação diária, com pessoas dependendo deles para fechar folha, admitir e escalar equipe.
Admissão sem papel, feita pelo celular
Em produção
O problema
Uma empresa de terceirização admitia pessoas com um formulário de 50 perguntas que não podia ser salvo pela metade. Documento chegava por WhatsApp, ficha era impressa, assinatura colhida à caneta e o dossiê montado à mão. Cada admissão levava semanas — para um público em que boa parte só tem o celular como computador.
A decisão
Antes de escrever código, foi preciso entender por que o processo era daquele jeito: o formulário longo existia porque a folha de pagamento exigia campos que ninguém sabia explicar, e o papel existia porque a assinatura precisava ter valor jurídico. Duas decisões saíram daí. A primeira foi quebrar o formulário em etapas com salvamento a cada campo, para que a pessoa possa parar e voltar. A segunda foi construir a assinatura eletrônica em casa, com manifesto de evidências no próprio PDF e verificador público por QR code, em vez de contratar serviço de terceiro.
O resultado
A pessoa é admitida pelo celular, sem senha e sem imprimir nada. Os documentos são capturados pela câmera com moldura guiada, o sistema sugere o preenchimento por leitura óptica sem nunca sobrescrever o que a pessoa digitou, e o dossiê sai pronto para os dois sistemas de folha usados pelo cliente — um com 28 colunas, outro com 97.
Detalhe técnico
A assinatura eletrônica foi a decisão mais difícil. Contratar um serviço pronto resolveria em uma semana, mas criaria dependência permanente de um terceiro para uma operação que acontece todo dia. Construir em casa exigia entender a Lei 14.063/2020 e o que, na prática, torna uma assinatura eletrônica simples defensável: registro de quem assinou, quando, de onde, e prova de que o documento não mudou depois.
O manifesto de evidências vai dentro do próprio PDF — hash do conteúdo, endereço de origem, dispositivo e data — e qualquer pessoa pode conferir pelo QR code impresso no documento, sem precisar de conta no sistema.
Férias e cobertura de posto, no mesmo cálculo
Em produção
O problema
Em terceirização, férias não são um saldo de dias. Cada posto de trabalho tem cobertura contratual obrigatória, então aprovar férias sem planejar o substituto deixa posto descoberto — o que quebra contrato com o cliente. Adiar demais gera multa por férias vencidas. A diretoria precisava responder "quantos intermitentes preciso em setembro?" e não tinha onde olhar.
A decisão
Nenhum sistema de mercado cruza as duas coisas, porque para o software genérico férias é um módulo de RH e escala é um módulo de operações. A decisão foi tratar os dois como o mesmo problema desde o modelo de dados: uma solicitação de férias só existe junto da pergunta "quem cobre este posto, e quanto custa". Isso mudou tudo o que veio depois — inclusive a decisão de nunca apagar registro histórico, apenas encerrar e criar, porque a contagem de período aquisitivo precisa sobreviver a qualquer correção cadastral.
O resultado
Ao aprovar férias, o sistema mostra o vão de cobertura, sugere o substituto e compara o custo de contratar um intermitente com o de aproveitar um ferista já no quadro. A diretoria pergunta em português e recebe a projeção de demanda por mês.
Detalhe técnico
O motor de cobertura é o que separa este sistema de um controle de férias comum. Ele parte do calendário de escala de cada posto, cruza com os períodos solicitados e devolve não apenas onde falta gente, mas quanto custa cada forma de resolver.
A validação legal ficou embutida no modelo, não em uma tela de alerta: o período aquisitivo, o limite de fracionamento e o prazo de gozo são calculados a partir dos registros históricos, que por isso nunca podem ser apagados. Correção cadastral encerra o registro anterior e cria um novo, preservando a linha do tempo.
Uma planilha entra, centenas de recibos assinados saem
Em produção
O problema
O Departamento Pessoal montava recibo de vale-alimentação e vale-transporte um a um, todo mês, copiando valores de uma planilha para um modelo de documento. Depois imprimia, distribuía, recolhia assinatura e arquivava. O trabalho crescia na mesma proporção do número de colaboradores.
A decisão
A tentação era construir um cadastro completo de benefícios. A decisão foi a oposta: não substituir a planilha. O DP já sabe usar planilha, já tem os valores lá, e a fórmula de cálculo é dele. O sistema recebe o arquivo que já existe, com as fórmulas nativas preservadas, e cuida apenas do que a planilha não faz — gerar o documento, distribuir e coletar a assinatura.
O resultado
O RH sobe a planilha e recebe os recibos prontos em segundos, cada colaborador com um link individual para assinar pelo celular. O disparo sai por e-mail e WhatsApp, e a tela mostra quem já assinou.
Detalhe técnico
A escolha de gerar o PDF em memória, sem subir um navegador headless para imprimir uma página, é o que mantém o tempo de resposta em segundos mesmo em lote. Um navegador por documento seria mais simples de escrever e inviável de operar.
O template de planilha que o sistema oferece para download traz as fórmulas nativas do Excel. O DP continua conferindo a conta na ferramenta que domina, e o sistema apenas lê o resultado.
Pedido de vaga por áudio vira requisição estruturada
Em produção
O problema
Requisições de pessoal chegavam ao RH por e-mail, WhatsApp e áudio, cada gestor descrevendo a vaga do seu jeito. Faltava informação, sobrava ambiguidade, e o RH gastava dias perguntando de volta o que já poderia ter vindo na primeira mensagem.
A decisão
Obrigar o gestor a preencher um formulário resolveria no papel e falharia na prática — ele continuaria mandando áudio. A decisão foi aceitar a mensagem no formato em que ela já chega e usar um modelo de linguagem para estruturá-la, devolvendo ao RH uma requisição com os campos preenchidos e um indicador de confiança por campo. O gestor não muda de hábito; o RH recebe estrutura.
O resultado
A requisição chega estruturada, com o custo, o tempo e a confiança de cada extração registrados. O que a IA não conseguiu determinar aparece marcado, para ser confirmado por uma pessoa — nunca preenchido por adivinhação.
Detalhe técnico
O detalhe de engenharia que vale mencionar não é a IA, é o teste de arquitetura. As cinco camadas do sistema não dependem de disciplina de quem escreve: existe um teste que percorre os imports e reprova qualquer um que atravesse a fronteira errada. A regra de arquitetura deixa de ser documento e passa a ser código que falha.
O rastro de cada chamada ao modelo — custo, latência e confiança — fica gravado. Sem isso, “a IA errou” é uma frase sem meio de verificação.
04Método
Metade do trabalho acontece antes da primeira linha de código.
Sistema que nasce de uma lista de funcionalidades resolve o pedido e erra o problema. As duas primeiras etapas abaixo são as que definem se as outras duas valem alguma coisa.
- 01Entender
Por que a regra é assim
Acompanhar o processo como ele acontece hoje, com quem o executa. Descobrir quais regras vêm de lei, quais vêm de contrato e quais são hábito que ninguém revisou. É aqui que se decide o que não construir.
Documento de requisitos e mapa do processo
- 02Decidir
Escolher com o custo à vista
Cada decisão técnica relevante é registrada com a alternativa que foi descartada e o motivo. Comprar ou construir, aceitar ou recusar um acoplamento, quanto de automação vale a pena.
Registros de decisão de arquitetura
- 03Construir
Em fatias que já servem
A primeira entrega precisa ser usável em produção, não uma demonstração. Cada incremento sai com teste automatizado e passa por integração contínua antes de subir.
Sistema em produção, com testes e publicação automatizada
- 04Sustentar
O projeto não acaba na entrega
Correção, evolução e a documentação que permite outra pessoa assumir. O código é seu, no seu repositório, com o histórico completo de como chegou até ali.
Acompanhamento e transferência de conhecimento
05Sobre
Uma pessoa responde por tudo. Inclusive depois.
A Fontes Mídias é conduzida por Bruno Fontes, que atua em gestão de pessoas e escreve os sistemas que apresenta aqui. Isso significa que quem levanta o requisito é quem decide a arquitetura e quem responde quando algo quebra.
Não há equipe de atendimento entre você e quem programa, e não há capacidade para muitos projetos ao mesmo tempo. É uma limitação real, e está dita aqui porque descobri-la depois seria pior.
O conhecimento do domínio veio do lado de dentro: os sistemas nasceram de processos de RH e departamento pessoal vividos na operação, não descritos em reunião.
E se eu sair de cena? O código é entregue no seu repositório, com o histórico de como cada parte chegou ali; as decisões de arquitetura ficam escritas, com a alternativa descartada e o motivo; a publicação é automatizada e a suíte de testes é sua. Isso não elimina o risco de uma operação individual, elimina o pior desfecho dele — ficar com um sistema em produção que ninguém consegue assumir.
06Contato
Descreva o processo. Não precisa saber a solução.
Quanto mais concreto for o relato do que acontece hoje — quem faz, em que ferramenta, quantas vezes por mês — melhor a primeira resposta. Se o caso não for para mim, digo isso na resposta.