O Petzara começou com uma observação simples: petshops que atendem bem, mas travam na operação manual. Agenda em caderno, histórico de cliente no WhatsApp, equipe sem visibilidade. O problema era claro. A solução precisava ser construída.
Por que um SaaS, não um app?
A primeira decisão foi escolher web sobre app nativo. O motivo: petshops usam múltiplos dispositivos — o computador da recepção, o celular do tosador, o tablet do gerente. Um sistema web responsivo resolve isso sem o overhead de duas codebases.
Além disso, web tem deploy instantâneo. Atualizar um sistema web é invisível para o usuário. Atualizar um app nativo exige aprovação nas lojas e que o usuário atualize manualmente.
A decisão mais difícil: modelar a agenda
O coração do Petzara é o sistema de agendamentos. E ele precisa ser confiável — dois agendamentos no mesmo horário, com o mesmo tosador, é um erro grave que prejudica o cliente e a empresa.
A solução não foi apenas validação no front-end. O banco de dados tem uma constraint que impede fisicamente dois agendamentos conflitantes. A validação no front-end existe para feedback imediato; a do banco existe como garantia final.
-- Constraint que impede conflitos de horário por funcionário
CREATE UNIQUE INDEX unique_appointment_slot
ON appointments (employee_id, date, time_slot)
WHERE status != 'cancelled';
O desafio do calendário
Implementar um calendário interativo de zero é complexo. Usamos FullCalendar, mas a integração com nosso modelo de dados exigiu customização significativa.
O calendário precisava:
- Mostrar agendamentos em tempo real (WebSocket)
- Filtrar por funcionário com cores diferentes
- Suportar arraste de agendamentos entre horários
- Funcionar bem no celular (principal dispositivo de uso)
O drag-and-drop mobile foi o ponto mais trabalhoso — eventos de toque têm comportamento diferente de mouse em calendários. A solução foi uma camada de abstração que mapeia eventos de toque para drag events.
Notificações: o que parecia simples
Enviar um WhatsApp de confirmação de agendamento parece simples. Na prática, envolve:
1. Fila de mensagens para não sobrecarregar a API 2. Rate limiting por número de telefone 3. Retry em caso de falha 4. Log de mensagens enviadas 5. Opt-out para clientes que não querem receber
O que começou como "manda uma mensagem" virou um microsserviço próprio.
O que aprendemos com os primeiros usuários
Os petshops que usaram nas primeiras semanas mostraram algo inesperado: a funcionalidade mais usada não era a agenda — era o histórico do pet.
"Qual produto eu usei no Buddy na última vez?" "Esse cachorro tem alergia a algum produto?" "Quanto tempo leva para tosá-lo?"
Isso nos fez priorizar o cadastro de pets com campos de observação, histórico de serviços e até upload de fotos. O produto ficou melhor por causa do uso real, não do planejamento.
Stack final
- Front-end: React + TypeScript + Tailwind CSS
- Back-end: Node.js + Express
- Banco: PostgreSQL com Prisma ORM
- Tempo real: WebSocket para atualizações de agenda
- Notificações: WhatsApp Business API + fila Redis
- Deploy: Vercel (front) + Railway (back + banco)
- Pagamentos: Stripe para assinaturas mensais
O que eu faria diferente
Se começasse hoje, usaria Next.js com App Router desde o início para ter SSR e SEO sem configuração extra. Também implementaria multi-tenancy no nível do banco de dados (schema por tenant) em vez de row-level security, que complica as queries.
Mas essas são melhorias arquiteturais. O core do produto — resolver o problema de agendamentos de petshops — funciona bem e está em uso real.
Isso é o que importa.