- Proceso
- TuBarberia
- Producto
- Laravel
- Barberías
Cómo construí TuBarberia: web, reservas y gestión para barberías
De la web app de una barbería real a un producto para muchas: qué quería resolver, cómo se usa, las decisiones que más me costaron y lo que todavía falta.
Ángel Muñoz Ruiz
· 6 min de lectura

TuBarberia es mi primer gran proyecto: un producto con el que una barbería tiene su web, recibe reservas online y lleva su agenda, sus clientes y sus cobros desde un panel. En la ficha del proyecto está el resultado, con el vídeo, las capturas y la demo. Aquí cuento el camino: qué quería resolver, qué decisiones me costaron más y qué queda por hacer.
Si prefieres verlo antes de leer, el vídeo de 2:36 de la ficha recorre la web, la reserva y el panel, con datos de demostración.
Lo que quería resolver
Una barbería pequeña vive de su agenda, y la agenda suele estar repartida entre WhatsApp, llamadas y una libreta. El barbero contesta con las manos ocupadas, los huecos libres no se ven desde fuera y los clientes de siempre dependen de su memoria. Quería que reservar fuera tan sencillo como escribir un mensaje y que, al otro lado, la cita apareciera ordenada sin que nadie tuviera que pasarla a limpio.
Empezó con una barbería real
TuBarberia parte de ILLAN BARBERS 2.0, la web app que hice para la barbería de José Luis Illán, en Murcia. Sus necesidades eran muy concretas: atiende él solo, en verano cambia de localidad, tiene clientes fijos y no quiere publicar su dirección exacta. Las escribí como una lista de reglas que se pudieran comprobar una a una: horas libres de verdad, ninguna cita doble, cancelación hasta 36 horas antes, avisos al barbero por Telegram.
Con esa base, lo que resolvía para una barbería concreta lo generalicé en un producto que cualquier barbería puede usar con su propia marca. ILLAN BARBERS sigue funcionando por su cuenta, como proyecto independiente.
De una web a un producto
Pasar de una web a un producto cambió el problema. Ya no bastaba con que la reserva funcionara: cada barbería necesitaba su web, su dirección y sus datos, y ninguna podía ver nada de otra. Y había que construir todo lo que rodea al producto: el alta sin ayuda, la prueba gratuita, la suscripción, una demo que se pudiera tocar y un panel de plataforma desde el que dar soporte con un acceso que queda registrado.
Todas las barberías comparten una sola base de datos, con cada tabla del negocio marcada con su barbería. Eso obliga a ser muy estricto: el código rechaza cualquier consulta que llegue sin una barbería en el contexto, en lugar de devolver datos de todas, y la propia base de datos impide enlazar una cita con un cliente de otra barbería. Hay pruebas automáticas que intentan justo eso, colarse en otra barbería, y tienen que fallar.
Las dificultades que más me enseñaron
Dos personas, la misma hora
Lo que más preocupa en un sistema de reservas es que dos clientes confirmen la misma hora a la vez. Lo resolví en dos capas: cada reserva toma un cerrojo de su barbería en la base de datos antes de mirar la agenda, y la agenda está dividida en tramos de cinco minutos con un índice único, de modo que, aunque algo fallara arriba, la base de datos rechazaría la segunda cita. Para probarlo lanzo dos procesos reales que reservan en paralelo.

Datos de demostraciónElige el servicioEl precio final, antes de elegir hora. 
Datos de demostraciónElige el díaSolo los días con horas libres se pueden pulsar.
El cambio de hora
Las fechas se guardan en UTC y cada barbería trabaja en su zona horaria. Parece un detalle hasta el último domingo de octubre, cuando un error así movería una cita de hora sin que nadie lo notara. Hay pruebas específicas para los días de cambio de hora.
Una entrada que no pasaba por la puerta
El panel usa Livewire, que tiene un mismo punto de entrada para actualizar las pantallas y responde en todos los dominios. En una revisión de seguridad apareció que esa entrada no pasaba por las mismas comprobaciones que el resto del panel. Lo cerré con una guarda que comprueba en cada petición que el panel y la barbería coinciden, y con pruebas que reproducen el intento.
Automatizar sin pasarse
No todo debía ser automático. WhatsApp se abre con el mensaje ya escrito, pero lo envía el barbero. Un Bizum no se marca como pagado hasta que él lo ve en su banco. Y aunque hay código para cobrar Bizum online, está apagado: con una sola cuenta de comercio, el dinero de todas las barberías acabaría en la misma cuenta, y eso no se arregla con un ajuste.

Datos de demostraciónPagosLos Bizum pendientes de comprobar aparecen primero; ninguno pasa a pagado solo.
Una demo en la que se puede tocar todo
Quería que cualquiera pudiera entrar al panel sin registrarse y probarlo de verdad. La demo envuelve cada petición en una transacción que se deshace al terminar, no envía correos ni avisos y se reinicia cada media hora con datos ficticios. Así se puede borrar, mover y cobrar sin estropear nada.
Lo que he aprendido
- Escribir las reglas del negocio como una lista comprobable: es la referencia para decidir y para probar.
- En un producto para varios clientes, el aislamiento tiene que estar en el código y en la base de datos desde el primer modelo, no añadirse al final.
- Un sistema de reservas se juega en los bordes: dos clientes a la vez, el cambio de hora, una cancelación a última hora.
- Automatizar también es decidir qué no automatizar.
Qué queda por mejorar
TuBarberia está publicado, pero no terminado. Lo siguiente:
- La agenda para varios profesionales: la primera parte está programada, pero hoy la agenda admite un solo profesional.
- Desplegar la capa extra de protección contra reservas falsas y bots, que ya está programada.
- Pruebas de principio a fin del recorrido de reserva en un navegador real.
- El cobro online sigue fuera: solo tendría sentido con una cuenta de cobro propia para cada barbería.