Estudo de caso
Gestão e Agendamento para Barbearias
Um produto multi-tenant com três superfícies conectadas a uma API central: gestão interna, reserva pública e landing comercial. O desafio reúne isolamento de dados, regras de disponibilidade e operação em fusos horários diferentes.
Minha responsabilidade
Produto, arquitetura, interfaces Flutter Web, integração da landing Next.js, backend, banco de dados e deploy.
Status de entrega
API em produçãoAPI colocada em produção na semana de 3 de outubro de 2026. Camisa 10 é a primeira landing personalizada ao vivo; a disponibilidade de todas as interfaces e a adoção do produto não estão estabelecidas.
Contexto e solução
Plataforma para operação de barbearias e agendamento de clientes. O ERP Flutter Web reúne equipe, serviços, horários e agendamentos; uma SPA pública Flutter Web resolve a barbearia por slug e permite reservar sem login. A landing Next.js direciona o visitante para esse fluxo.
Visão de produto
A proposta conecta operação e aquisição de clientes: cada barbearia pode ter uma experiência pública com identidade própria, conduzindo visitantes ao agendamento online. Camisa 10 é a primeira implementação ao vivo dessa camada de marca.
Experiência pública personalizada
Experiência pública
A Barbearia Camisa 10 é a primeira landing personalizada ao vivo dessa estratégia. Sua identidade visual apresenta a marca e os serviços, enquanto os CTAs conduzem à SPA Flutter Web de agendamento, no slug da barbearia.
- 01Landing personalizada
- 02Agendamento público
- 03API central
- 04Gestão interna
Agendamento público · Flutter Web
Captura da SPA de agendamento será adicionada após o redesign da interface.
Experiência de gestão interna
O ERP Flutter Web organiza equipe, serviços, horários e reservas por funcionalidades, com Riverpod, go_router e Dio. A gestão e o agendamento público compartilham a API central; os fluxos internos são protegidos por JWT.
Arquitetura
Monólito modular Python/FastAPI, contratos Pydantic, persistência SQLAlchemy/psycopg e migrações Alembic. A landing Next.js, a SPA pública Flutter Web e o ERP Flutter Web compõem superfícies distintas do mesmo produto.
Diagrama da arquitetura implementada. A confirmação de produção refere-se à API; CI/CD e garantias PostgreSQL contra reservas concorrentes fazem parte da evolução planejada.
Multi-tenancy e autorização
Tabelas PostgreSQL compartilhadas usam isolamento lógico por tenant_id. Papel e tenant vêm do usuário persistido nos fluxos internos. Na entrada pública, a barbearia é resolvida por slug e as associações entre tenant, serviço e profissional são validadas.
Agendamento e fusos horários
A disponibilidade considera horários de trabalho, intervalos, duração do serviço e reservas existentes. Cada tenant tem um fuso IANA: apresentação no horário local e persistência/comparação em UTC. No ERP, Riverpod, go_router e Dio apoiam a organização por funcionalidades.
Entrega e resultado
API e PostgreSQL em Docker Compose em VPS DigitalOcean, com Nginx e migrações versionadas. O produto combina gestão interna com agendamento público e um modelo reutilizável de tenants. O backend foi colocado em produção.
Restrições e trade-offs
O monólito modular evita complexidade prematura de microsserviços. O isolamento por tenant_id depende de aplicação consistente das regras de acesso. O cálculo de disponibilidade não substitui uma garantia transacional: a checagem seguida de inserção ainda pode permitir disputa entre reservas simultâneas.
Qualidade e próximos passos
Existem testes backend para isolamento e agendamentos, além de testes Flutter. Os testes backend usam SQLite em memória e não provam comportamento específico do PostgreSQL. Garantias transacionais contra reservas concorrentes, testes PostgreSQL, revisão de autorização, validação de horários no servidor, observabilidade e CI/CD são próximos passos, ainda não concluídos.
Tecnologias utilizadas
Próximo estudo de caso
Olá Cliente