Ponto da Cafeteria

O problema

O negócio precisava de um jeito simples para a equipe registrar início e fim do turno pelo celular. A gestão também precisava de uma visão confiável de presença, turnos incompletos, pedidos de ajuste, horas trabalhadas e horas extras semanais.

A primeira versão tinha de ser barata, fácil de usar no navegador e pequena o bastante para validar antes que a complexidade da operação se acumulasse.

Descoberta e restrições

• O fluxo de quem registra o ponto precisava funcionar bem no celular.
• Os fluxos da equipe e da gestão precisavam de telas separadas.
• Dados de presença e códigos de acesso individuais não podiam aparecer no repositório público.
• As horas extras precisavam seguir um limite semanal, em vez de tratar o trabalho no fim de semana como hora extra automaticamente.
• A primeira entrega excluiu, de propósito, GPS e um aplicativo nativo.

Principais decisões

Navegador primeiro, não app nativo

Um fluxo no navegador eliminou o atrito de instalação e manutenção para uma operação pequena.

Experiências separadas para equipe e gestão

A ação diária da equipe continua focada, enquanto o histórico e a revisão de ajustes ficam no fluxo da gestão.

Regras semanais de horas extras

A aplicação avalia as horas extras contra o limite semanal, o que evita classificar o trabalho no fim de semana, por si só, como hora extra.

Snapshot público em vez do código operacional

O case público usa exemplos fictícios e documentação no nível do schema. Os dados da operação ficam fora do controle de versão e fora do portfólio.

Fluxo da solução

Quem trabalha se identifica
-> registra o início ou o fim do turno
-> a API Node.js valida e guarda o evento
-> o PostgreSQL agrupa os eventos em períodos trabalhados
-> os cálculos geram totais diários, semanais e mensais
-> a gestão revisa histórico, alertas, horas extras e pedidos de ajuste

Engenharia e confiabilidade

• Interface web mobile-first.
• API REST em Node.js que também serve o frontend.
• PostgreSQL hospedado no Supabase.
• Testes de cálculo de horas, horas extras semanais, histórico diário, alertas de ponto e pendências da gestão.
• Alertas para registros incompletos ou duplicados.
• Pedidos de ajuste ficam fora do cálculo até a aprovação da gestão.

Resultado e evidências

• A aplicação está em uso no fluxo real, confirmado em 27/08/2026.
• O snapshot sanitizado documenta o fluxo do produto, as restrições e o limite do que é público.
• O comportamento de horas, horas extras e alertas é coberto por nove testes automatizados no snapshot público.
• O repositório operacional continuou evoluindo depois do snapshot: em outubro de 2026 recebeu correções para confirmar o ponto salvo, rastrear falhas de registro e alinhar o cálculo de horas aos alertas. O repositório público continua sendo o snapshot de agosto.

A evidência aqui é o uso operacional e os testes das regras. Tempo economizado, volume de uso e impacto financeiro não foram medidos neste case.

O que aprendi

Uma ferramenta operacional pequena se torna confiável quando suas regras de negócio são explícitas. A interface é só uma parte do produto; as definições por trás de horas extras, turnos incompletos e correções aprovadas determinam se as pessoas podem confiar nela.

O que eu melhoraria a seguir

• Confirmar a próxima necessidade da operação pela observação do uso, antes de ampliar o escopo.
• Reforçar autenticação e controle de acesso só quando o fluxo leve atual deixar de servir à operação.
• Manter os exemplos públicos sintéticos e revisar cada captura de tela antes de publicar.