Case study
Barbershop Management & Booking Platform
A multi-tenant product with three surfaces connected to a central API: internal management, public booking and a commercial landing. The challenge combines data isolation, availability rules and operation across timezones.
My responsibility
Product, architecture, Flutter Web interfaces, Next.js landing integration, backend, database and deployment.
Delivery status
API in productionAPI put into production in the week of October 3, 2026. Camisa 10 is the first live branded landing; availability of all interfaces and product adoption are not established.
Context and solution
A platform for barbershop operations and customer booking. The Flutter Web ERP covers teams, services, working hours and appointments; a public Flutter Web SPA resolves the shop by slug and accepts bookings without login. The Next.js landing directs visitors into that flow.
Product vision
The product strategy connects operations and customer acquisition: each barbershop can have a public experience with its own identity, directing visitors to online booking. Camisa 10 is the first live implementation of this branded layer.
Branded customer acquisition
Public experience
Barbearia Camisa 10 is the first live branded landing implementing this strategy. Its visual identity introduces the brand and services, while its CTAs lead to the Flutter Web booking SPA at the barbershop's slug.
- 01Custom landing
- 02Public booking SPA
- 03Central API
- 04Internal management
Public booking · Flutter Web
A booking SPA screenshot will be added after the interface redesign.
Internal management experience
The Flutter Web ERP organizes teams, services, working hours and appointments by feature, using Riverpod, go_router and Dio. Management and public booking share the central API; internal flows are protected by JWT.
Architecture
A modular Python/FastAPI monolith, Pydantic contracts, SQLAlchemy/psycopg persistence and Alembic migrations. The Next.js landing, public Flutter Web SPA and Flutter Web ERP are distinct surfaces of the same product.
Diagram of the implemented architecture. Production confirmation refers to the API; CI/CD and PostgreSQL safeguards against concurrent bookings are planned improvements.
Multi-tenancy and authorization
Shared PostgreSQL tables use logical tenant_id isolation. Internal flows derive role and tenant from the persisted user. Public entry resolves the shop by slug and validates tenant, service and barber associations.
Scheduling and timezones
Availability considers working hours, breaks, service duration and existing appointments. Each tenant has an IANA timezone: display in local time and persistence/comparison in UTC. Riverpod, go_router and Dio support a feature-oriented ERP structure.
Delivery and outcome
API and PostgreSQL deployed with Docker Compose on a DigitalOcean VPS, with Nginx and versioned migrations. The product combines internal management with public booking and a reusable tenant model. The backend was put into production.
Constraints and trade-offs
The modular monolith avoids premature microservice complexity. Tenant_id isolation depends on consistent access-rule enforcement. Availability calculation does not replace a transactional safeguard: a check followed by an insert can still race under simultaneous booking requests.
Quality and next steps
Backend tests cover isolation and appointments, alongside Flutter tests. Backend tests use in-memory SQLite and do not prove PostgreSQL-specific behavior. Transactional safeguards against concurrent bookings, PostgreSQL tests, authorization review, server-side slot validation, observability and CI/CD are next steps, not completed capabilities.
Technology stack
Next case study
Olá Cliente