Slotwise
Agendamento online para barbearias, estúdios e clínicas.
Uma página de agendamento para cada negócio, em inglês e em dólares, onde o cliente escolhe serviço, profissional e um horário livre em três passos, e um painel para a recepção tocar o dia: agenda com arrastar para remarcar, agendamentos, clientes, serviços, equipe, horários de funcionamento, registro de lembretes e análises. Dois negócios de demonstração: uma barbearia no Brooklyn e um estúdio de Pilates em Austin, cada um no seu fuso horário.
Agende em /b/ironside-barbers ou /b/lumen-pilates; nada é cobrado e os lembretes são só registrados. Painel em /dashboard com a senha demo (somente leitura).
- Tempo ativo de construção
- 2 h 42 min
- Agentes
- 5 agentes
- Testes passando
- 113
- Linhas de código
- 14.304
- Dependências em produção
- 5
Construído por um squad App Factory de 5 agentes Claude Code dentro do Cadrix: um líder no Opus que planejou, revisou e entregou, e quatro especialistas (Backend, Data, Frontend e QA) trabalhando em paralelo a partir do sexto minuto. 2 h 42 min de trabalho ativo, sem nenhuma linha de código escrita por uma pessoa. O tempo de relógio foi maior, cerca de 28 horas (de 7 de outubro, 19:58, a 8 de outubro, 23:59 UTC), porque a assinatura do Claude chegou ao limite de uso duas vezes e o trabalho ficou parado por 20 h 57 min e depois por 4 h 22 min; nas duas vezes, uma mensagem curta mandou o líder retomar. Os tempos vêm dos registros de sessão dos agentes, da gravação do canvas, do histórico do git e do registro de construção.
Veja o squad trabalhando
Time-lapse do canvas do Cadrix, um quadro a cada 30 segundos, em 31 segundos. As duas pausas pelo limite de uso foram cortadas e estão marcadas. Os últimos 19 minutos não foram filmados, então o quadro final é o canvas como o squad o deixou, capturado depois. No começo, o modo foco mostra todos os agentes de uma vez.
O que ele faz
- Página pública de agendamento por negócio: capa, equipe, horário e avaliação, e um fluxo em três passos (serviço, profissional e horário, seus dados) com resumo fixo no desktop e barra inferior no celular
- Motor de disponibilidade que respeita horário de trabalho, intervalos, folgas, folga entre atendimentos, antecedência mínima e o prazo máximo de agendamento, com a opção "qualquer profissional"; seguro nas trocas de horário de verão
- Link de gestão para cada agendamento: remarcar ou cancelar dentro da janela do negócio (12 h na barbearia, 24 h no estúdio), além de um arquivo de calendário (.ics) para baixar
- Agenda do painel por semana ou dia, com cores por profissional, arrastar para remarcar e conflitos recusados antes de acontecer
- Agendamentos, clientes, serviços, profissionais, horários e folgas; lembretes por SMS e e-mail 24 h e 2 h antes, registrados e nunca enviados
- Análises em SVG: agendamentos, receita, ticket médio, taxa de não comparecimento, ocupação por profissional, receita semanal e horários de pico, com visão em tabela; dados de demonstração com 150 clientes e cerca de 2.200 agendamentos
Como foi construído
- 0–6 minLíder: projeto montado, contrato da API, modelo de dados e plano na nota do time, um script de release; os quatro especialistas acionados de uma vez
- 6–51 minEm paralelo: o Data escreveu o schema e os dados de demonstração, o Backend o motor de disponibilidade, a autenticação e todas as rotas da API, o Frontend a landing, o fluxo de agendamento e a página de gestão, o QA o Playwright e os testes de API. Primeira versão no ar aos 51 min
- 52 minO pedido ao Frontend expirou com o painel pela metade, e o trabalho parou no limite de uso por 20 h 57 min
- 52–80 minRetomada: o líder salvou o painel ainda não commitado do Frontend como checkpoint e o reenviou; painel publicado e revisado no ar em 390 e 1440 px
- 80–143 minRodada de correções do Frontend, Data e Backend em paralelo, depois uma rodada de acabamento; testes todos verdes. Então o limite de uso voltou e o trabalho parou por 4 h 22 min
- 143–162 minRetomada: layout de horários no celular, verificação final do QA, um bloqueio corrigido com teste de regressão, release final
Problemas que os agentes resolveram
- O primeiro pedido ao Frontend expirou com cerca de 3.300 linhas do painel sem commit, e em seguida o limite de uso parou todo o trabalho. Na retomada, o líder confirmou que o código ainda compilava e passava na checagem de tipos, fez um commit de checkpoint e mandou o Frontend terminar a partir dali. Nada se perdeu.
- A segunda pausa pelo limite de uso (o chat mostra "You've hit your session limit") interrompeu duas tarefas antes que mudassem qualquer coisa. Quando o limite voltou, o líder conferiu no git o que tinha ficado por fazer e reenviou as duas.
- A revisão do próprio líder na primeira versão completa achou seis problemas: a página de agendamento no celular esticando para 848 px, oito itens estourando o menu do painel no celular, telas em branco durante o carregamento, uma agenda semanal ilegível, dias futuros quase lotados e um registro de lembretes levando 680 ms. Frontend, Data e Backend corrigiram em paralelo; o registro agora responde em cerca de 6,5 ms.
- O QA descobriu que cancelar um agendamento falhava em produção: o navegador mandava o tipo de conteúdo JSON em requisições sem corpo, e o servidor respondia 400. A correção foi feita dos dois lados.
- Na verificação final o QA bloqueou a entrega: o menu do painel usava links relativos, então cada clique se somava à URL. O líder trocou por links absolutos dois minutos depois, e o novo teste de regressão do QA passa no desktop e no celular.
- Achados menores no caminho: Data e Backend tinham escrito cada um suas funções de fuso horário, unificadas em uma só; o fallback com dados de exemplo foi removido para a produção não esconder falhas da API; e um helper de teste que escolhia um horário anterior ao pedido foi corrigido quando mais horários ficaram livres.
Tecnologias
Node 22Fastifynode:sqliteReactReact RouterViteVitestPlaywright
Mais telas
Construa o seu do mesmo jeito.
Uma máquina privada com Claude Code, Codex e Pi num só canvas.