Vain

Prestadores de serviço autônomos — barbeiros, cabeleireiros, esteticistas — gerenciam a agenda no WhatsApp, em cadernos físicos ou em planilhas. Isso gera confusão, no-shows sem punição e tempo perdido com confirmações manuais. A Vain nasceu para resolver isso: uma plataforma onde o prestador configura seus serviços e disponibilidade uma vez, e os clientes agendam sozinhos pela internet, sem precisar falar com ninguém.

O que ele faz

Cada prestador tem uma página pública de booking com URL própria. O cliente entra, escolhe o serviço, seleciona um horário disponível e confirma — tudo em menos de dois minutos.

Por trás disso, o prestador tem um portal completo de gestão:

• Calendário visual com todos os agendamentos
• Configuração de horários, pausas e períodos fechados
• Serviços com preço, duração e taxa de reserva opcional
• Formulários personalizados que o cliente preenche ao agendar
• Gestão de clientes com histórico, notas e lista negra
• Pagamentos via Stripe Connect — a taxa de cancelamento ou depósito vai direto para a conta do prestador
• Sincronização com Google Calendar
• Lembretes automáticos por email e WhatsApp

Decisões técnicas

Por que NestJS no backend? A agenda tem regras complexas: antecedência mínima, otimização de slots para evitar "buracos", auto-cancelamento de agendamentos expirados, cobranças automáticas. NestJS com sua arquitetura modular e suporte nativo a filas (BullMQ) deixou esse domínio organizado. Cada feature vive num módulo isolado — alterações em pagamentos não tocam em calendário.

Stripe Connect como trade-off central Poderíamos ter guardado o dinheiro e repassado depois — mais simples tecnicamente. Escolhemos Stripe Connect para que cada prestador tenha sua própria conta e receba diretamente. Isso aumentou a complexidade de onboarding, mas eliminou risco regulatório de "guardar dinheiro de terceiros" e gerou muito mais confiança dos prestadores.

Disponibilidade calculada em tempo real O maior desafio técnico: calcular os slots disponíveis considerando horários de funcionamento, breaks, períodos fechados, agendamentos existentes, tempo extra de cada serviço e otimização de agenda (evitar slots que gerariam buracos improdutivos). Acabei escrevendo um algoritmo próprio que roda no backend a cada request de disponibilidade — simples de testar e fácil de ajustar conforme novos casos de uso aparecem.

O que aprendi: Agendamento parece simples até você começar a lidar com timezones, conflitos de concorrência e edge cases de cancelamento. Modelar bem o domínio antes de escrever código teria economizado semanas.

Outro aprendizado importante foi que os prestadores tinham necessidades que não antecipamos. O que planejávamos como próximo passo frequentemente ficou para depois, porque surgiam demandas mais urgentes dos próprios usuários — coisas que não estavam no roadmap mas que eram bloqueantes para eles no dia a dia. Aprendemos cedo que nossa percepção do que era prioritário raramente coincidiu com a realidade de quem usa o produto.

Resultados

O projeto ainda está em fase inicial — early traction, não lucrativo:

• 3 prestadores usando ativamente a plataforma
• +5.000 agendamentos processados
• R$200/mês de receita recorrente (MRR)

O aprendizado mais valioso foi perceber que o problema de onboarding do prestador (configurar serviços, horários, conectar Stripe) era maior do que o booking em si. A próxima fase é simplificar esse fluxo para reduzir o tempo de ativação.