Como criar um app de controle de horas sem código

Como criar um app de controle de horas sem código

Você descreve quem registra, o que precisa aparecer em cada lançamento e o que quer ver no fim do mês. O Zugo gera o app com cronômetro ou lançamento manual, lista por período e total por cliente, verifica numa sandbox e publica em seu-slug.zugo.run. A construção custa 600 créditos, e o banco entra pela integração com o Supabase.

Um aviso logo no começo, porque ele muda a decisão de muita gente: controle de horas para faturar cliente e registro de ponto para fins trabalhistas são coisas diferentes, e este guia trata da primeira.

Planilha de horas ainda resolve o problema?

Resolve enquanto o uso é individual e a memória colabora. Se você atende dois clientes e anota no fim do dia, a planilha é gratuita, você já domina e não exige manutenção nenhuma.

Ela começa a falhar em três situações. Quando mais de uma pessoa lança e alguém apaga uma fórmula sem perceber. Quando o registro precisa acontecer na hora, no celular, entre uma reunião e outra. E quando você quer regra: projeto obrigatório, hora que não pode se sobrepor, mês fechado que ninguém edita depois.

O terceiro ponto é o que mais dói em agência e em quem trabalha por hora. Planilha aceita qualquer coisa, inclusive oito horas lançadas num projeto encerrado em março. Um app com formulário e banco valida antes de o dado entrar, e não numa auditoria dolorosa no fim do trimestre.

Existe ainda o caso de quem precisa mostrar as horas ao cliente. Mandar uma aba de planilha compartilhada é frágil; um relatório por período dentro do seu domínio passa outra impressão e não expõe o resto da sua operação.

O que o app precisa ter para ser usado todo dia?

Registro em menos de dez segundos. Essa é a única característica que decide se o app sobrevive ao segundo mês, e todo o resto vem depois dela.

A maioria das pessoas acha que quer cronômetro e usa lançamento manual. O cronômetro exige lembrar de parar, e a reunião que emenda em outra deixa quatro horas contadas para uma tarefa de quarenta minutos. Ter as duas formas na mesma tela é o desenho que costuma sobreviver.

Além do registro, três coisas na tela inicial bastam: total da semana, total do mês por cliente e o último lançamento com botão de repetir. Painel com oito indicadores é bonito na primeira semana e ignorado na terceira.

Como escrever o prompt que gera o app de horas?

Diga quem usa, o que cada lançamento precisa ter e o que você quer ver no fechamento. Essa última parte é a que mais evita edição depois.

App de controle de horas para [autônomo / agência com 5 pessoas],
com login por e-mail.
Cadastro de clientes e, dentro de cada cliente, de projetos.
Lançamento com data, duração em horas e minutos, projeto,
descrição curta e marcação de faturável ou não.
Duas formas de registrar: cronômetro e lançamento manual.
Telas: registrar, lista do período com filtro por cliente e por
pessoa, e fechamento com total de horas por cliente no mês.
Marcar um mês como fechado para bloquear edição.
Exportar o período em CSV.

Compare com "faça um app de horas". Os dois geram algo. Só o primeiro traz a marcação de faturável, que é justamente o campo que ninguém pede e todo mundo precisa quando chega a hora de separar o trabalho cobrado do trabalho interno.

O campo de descrição curta merece atenção. Ele é o que vira a linha do relatório enviado ao cliente, então vale exigir no formulário em vez de deixar opcional. Descrição vazia hoje é reunião constrangedora daqui a trinta dias.

Como ligar horas a cliente, projeto e valor?

Com uma hierarquia de dois níveis: cliente contém projetos, projeto contém lançamentos. Três níveis (cliente, projeto, tarefa) parecem mais organizados e quase sempre atrapalham, porque obrigam a escolher três coisas antes de registrar quinze minutos.

O valor por hora fica no projeto, não no lançamento. Isso permite que o mesmo profissional cobre diferente de clientes diferentes sem retrabalho, e evita que alguém digite valor errado na pressa.

Se a sua agência tem custo por pessoa e preço por cliente diferentes, são dois campos distintos: quanto aquela hora custa e por quanto ela é vendida. A diferença entre os dois é a margem do projeto, e ver esse número por cliente costuma mudar a decisão de quem continuar atendendo.

Um detalhe que economiza discussão: guarde o valor da hora no momento do lançamento, e não só na configuração do projeto. Quando o preço subir em julho, os lançamentos de maio precisam continuar valendo o preço de maio. Essa é uma regra de negócio específica, do tipo que se afina em uma ou duas rodadas de edição.

Onde os dados ficam e quem enxerga o quê?

No Supabase, que é a integração responsável por banco de dados, login e arquivos. Cada pessoa entra com o próprio acesso, e o lançamento fica vinculado a quem registrou.

Em equipe, aparecem no mínimo dois papéis. Quem lança vê os próprios registros e os projetos em que está alocado. Quem administra vê tudo, fecha o mês e exporta. Misturar os dois é o erro mais comum e o mais desconfortável, porque expõe as horas de uma pessoa para as outras sem necessidade.

Se o app vai ser aberto ao cliente para ele acompanhar as horas, isso é um terceiro papel, com acesso somente de leitura e limitado aos projetos dele. Vale construir esse acesso depois que a rotina interna estiver funcionando, e não junto: projeto com três papéis desde o primeiro dia costuma virar plataforma multipágina.

Exportação em CSV vale pedir desde a primeira versão. É a garantia de que os números saem dali sem depender de ninguém, inclusive de nós. O panorama de projetos com banco e login aparece em como criar um quadro kanban.

Quanto custa em créditos montar e manter o app?

Créditos são consumidos para gerar e para editar. Publicar não custa nada, e usar o app depois de publicado também não.

O plano gratuito dá 2.400 créditos, que dá para quatro construções, então serve para experimentar. O Pro custa $25 por mês com 20.000 créditos, o equivalente a cerca de 16 plataformas multipágina, 33 construções ou 66 edições. O Business custa $50 por mês com 20.000 créditos.

Na prática, o gasto se concentra no primeiro mês de uso real. Você registra duas semanas, descobre que falta o campo de faturável, edita. Descobre que o filtro por pessoa é mais usado que o filtro por projeto, edita de novo. Quatro a seis rodadas até estabilizar é o padrão, e depois disso o consumo cai a quase nada.

Como transformar as horas em cobrança no fim do mês?

O caminho mais simples é fechar o mês no app, exportar o CSV por cliente e emitir a cobrança onde você já emite. Isso funciona desde o primeiro dia e não exige integração nenhuma.

Quem quer o passo seguinte pode gerar a cobrança dentro do próprio projeto, somando as horas faturáveis do período e aplicando o valor da hora. Se a cobrança for recebida online, o Stripe é a integração que cuida de pagamento e assinatura. O desenho completo desse projeto está em como criar um app de emissão de cobranças.

Vale incluir no relatório do cliente as horas não faturáveis marcadas como cortesia, quando for o caso. Mostrar o que não foi cobrado é uma das formas mais baratas de defender o próprio preço, e o dado já está lá.

E feche o mês de verdade, com bloqueio de edição. Sem isso, alguém vai ajustar abril em junho e o total nunca mais vai bater com o que foi cobrado.

Serve como controle de ponto para fins trabalhistas?

Não. Esse é o limite mais importante deste guia, e ele merece ser dito sem rodeio: registro de jornada de funcionário no Brasil segue exigência legal específica, com requisitos próprios de sistema, e um app gerado por descrição não é um sistema homologado para isso.

O que este app faz bem é medir tempo por projeto e por cliente, para faturar, orçar melhor e entender onde a semana foi embora. Isso é gestão, não é folha de pagamento.

Se a sua necessidade é ponto de funcionário celetista, a resposta honesta é procurar uma solução própria desse mercado e conversar com quem cuida do seu departamento pessoal ou com a sua contabilidade. Construir uma alternativa caseira aqui não economiza dinheiro, cria risco.

A fronteira é simples de enxergar: se o número vai para um cliente, este app resolve; se o número vai para a folha, ele não é o lugar.

Que erros fazem o registro de horas ser abandonado?

Formulário longo. Cada campo obrigatório a mais reduz a chance de registrar na hora, e registro adiado vira estimativa inventada no fim da semana.

Falta de edição rápida. Ninguém acerta a duração de primeira, e um app que exige quatro toques para corrigir quinze minutos ensina a pessoa a não corrigir nada.

Nenhum retorno visível. Se o app só engole horas e nunca mostra nada útil para quem lança, ele vira obrigação. Um total da semana na tela inicial já resolve boa parte disso.

Ausência de fechamento e de exportação. Sem fechamento, o dado muda para trás; sem exportação, você fica preso à ferramenta. A mesma lógica vale para qualquer registro contínuo, como aparece em como criar um app de controle de gastos.

O que o Zugo não faz aqui e por onde começar?

Ele não substitui um time de desenvolvimento num produto complexo. Integração com ferramenta de projeto existente, cálculo de folha e conformidade trabalhista são domínios com regra própria, e o caminho realista é aproximar por edições ou, se o projeto crescer, exportar o código pelo GitHub e seguir com uma pessoa desenvolvedora.

Antes de abrir a ferramenta, escreva a lista dos seus clientes e projetos ativos e decida uma coisa só: cronômetro, lançamento manual ou os dois. Essa decisão vale mais que qualquer recurso extra.

Depois gere a primeira versão, registre três dias de verdade e confira se o total do mês bate com o que você faria na mão. Dá para começar em zugo.dev pelo plano gratuito e ligar login, papéis e exportação quando a rotina já estiver de pé.