← Volver a trabajos realizados

Caso de estudio · Full-stack

LB Barber Studio

Turnos online y panel de administración para una barbería real en San Nicolás. Lo diseñé, desarrollé y sigo manteniendo en producción de punta a punta: base de datos, seguridad, frontend y despliegue.

  • HTML / CSS / JS
  • Supabase
  • PostgreSQL
  • Row Level Security
  • PWA
  • GitHub + Netlify CI/CD
Reserva de turno en LB Barber Studio: calendario y horarios disponibles

La reserva: el cliente elige el día y ve, en el momento, los horarios realmente libres — ni pasados, ni ocupados, ni bloqueados a mano.

El contexto

Luciano, el barbero, coordinaba todos sus turnos por WhatsApp: cada cliente preguntaba disponibilidad, él revisaba su agenda a mano y contestaba uno por uno. Necesitaba que los clientes pudieran reservar solos, sin choques de horario ni ida y vuelta de mensajes, y un panel propio para ver su día, bloquear horarios y cargar los clientes que vienen siempre a la misma hora.

Mi rol

Full-stack, solo: diseño del esquema de base de datos y de las políticas de seguridad en Supabase, el sitio público de turnos, el panel de administración con login real, la lógica de disponibilidad en tiempo real, el flujo de confirmación y cancelación por WhatsApp, y la app instalable (PWA) tanto para el sitio como para el panel.

Arquitectura

El mismo enfoque que en Lumil: sitio estático sin build step, con Supabase como backend completo y Row Level Security como única capa de seguridad real. Por defecto no se puede leer ni ejecutar nada; el cliente solo tiene acceso a un puñado de funciones puntuales (ver disponibilidad, reservar, cancelar), nunca a las tablas directamente.

  1. Sitio y panel — HTML, CSS y JavaScript sin build step, corriendo directo en el navegador.
  2. Supabase — PostgreSQL, autenticación y funciones de seguridad como backend completo.
  3. Row Level Security — las tablas están cerradas por defecto; solo funciones públicas puntuales exponen lo necesario.
  4. GitHub → Netlify — cada git push a master despliega el sitio y el panel automáticamente.

Problemas que resolví

Casos límite reales, no ejercicios de tutorial

Dos personas, un mismo horario

Si dos clientes reservan el mismo turno al mismo tiempo, la base de datos rechaza al segundo. No es una validación del frontend: es una restricción real en la tabla.

Disponibilidad calculada, no cargada a mano

Una sola función cruza el horario comercial del día, la hora actual, los turnos ocupados, los bloqueos manuales y los clientes fijos, y devuelve qué horarios están realmente libres.

Clientes fijos, con excepciones

Un cliente que viene todas las semanas, cada dos o cada cuatro, se carga una sola vez. Si un día no puede venir, se libera ese horario puntual sin tocar el resto de la serie.

Cancelación sin cuenta ni contraseña

Cada turno tiene un enlace propio de cancelación por WhatsApp, con un token único. Pasado el límite de horas antes del turno, el enlace deja de funcionar solo.

Un solo formato de teléfono

Con o sin 0, con o sin 15, con o sin +54: el número se normaliza siempre al mismo formato, para que nunca queden cargados dos números distintos de la misma persona.

Siempre en hora argentina

Qué día es "hoy" y qué turno ya "pasó" se calcula explícitamente en huso horario de Buenos Aires, sin depender de dónde esté corriendo el servidor.

Panel de administración de LB Barber Studio: pantalla de acceso

El panel: acceso autenticado con Supabase Auth. Sin login válido, Row Level Security bloquea cualquier consulta a los turnos reales.

Stack técnico

  • FrontendHTML5, CSS3, JavaScript vanilla — sin framework ni build step
  • BackendSupabase: PostgreSQL, Auth, funciones RPC, Row Level Security
  • ComunicaciónConfirmación y cancelación de turnos por WhatsApp, con enlaces únicos por turno
  • App instalablePWA con íconos propios, para el sitio de turnos y para el panel
  • InfraestructuraGitHub + Netlify, con despliegue continuo en cada push a master
¿Por qué sin framework? La misma decisión que en Lumil, y por el mismo motivo: sin build step significa cero fricción para desplegar, y el alcance de un sistema de turnos no justifica la complejidad de un framework. La señal para migrar sería más estado compartido entre pantallas, no más líneas de código.

¿Te sirve algo así?

Hablemos de tu proyecto

Si tu negocio necesita turnos online, un panel propio o algo a medida, te cuento cómo lo encararía.

Contame tu proyecto