El primer commit y la regla que rige todas las pantallas

A finales de noviembre hicimos el primer commit serio. Hasta entonces solo había prototipos sueltos, exploraciones de diseño en Figma y una pila de notas. El primer commit era el equivalente a escribir "página 1" en una novela que llevábamos meses pensando: emocionante y un poco intimidante.

Lo más útil de esos seis meses previos no fue tanto lo que aprendimos sobre el sector como una regla que decidimos imponernos antes de empezar a teclear.

La regla de oro

Está escrita literalmente en el README del repositorio:

Si una pantalla necesita explicación, está mal hecha.

Suena obvio. No lo es. La mayoría de software de gestión que hemos visto requiere un onboarding de media hora con un comercial. Eso no es porque los hosteleros sean torpes: es porque el producto es opaco. Etiquetas confusas, flujos que se bifurcan sin avisar, botones que dicen "Aceptar" cuando deberían decir "Confirmar reserva".

La regla nos obliga a varias cosas:

• Texto explícito en los botones. Nada de "Guardar" a secas. "Guardar carta", "Guardar mesa 12", "Confirmar cambios".
• Vacíos con instrucciones. Cuando una pantalla está vacía (sin reservas, sin platos, sin clientes), no se ve un cuadro gris triste. Se ve qué se puede hacer y un botón claro para empezar.
• Tooltips solo para casos extremos. Si necesitas un tooltip, probablemente el diseño está mal y hay que reescribir el flujo.

Qué entró en ese primer commit

El primer commit no era impresionante. Tenía:

• Una estructura de carpetas con features/ por dominio (auth, dashboard, reservations, menu, customers).
• El esqueleto de autenticación contra Supabase.
• Una pantalla de login funcional, fea, pero suficiente para empezar.
• Un componente de layout con el selector de restaurante arriba.

Y poco más. La gracia no era el código; era que existía un sitio donde escribirlo.

Lo que cambió cuando empezamos a teclear

Hay decisiones que solo se pueden tomar mientras programas, no antes. Algunas que aparecieron las primeras semanas:

• El editor de carta tenía que admitir arrastrar y soltar bloques. En Figma se veía bonito; en el código nos costó dos intentos hacerlo decente.
• El estado de las reservas no eran cuatro estados, eran siete. Hicieron falta otras tres entrevistas para confirmarlo.
• El selector de restaurante no podía recargar la página: tenía que mantener el contexto de lo que estabas haciendo.

Cómo medimos si la regla funciona

Cuando alguien externo prueba una pantalla por primera vez, no le explicamos nada. Le dejamos delante y observamos. Si tarda más de cinco segundos en saber qué tiene que hacer, esa pantalla no pasa. La rehacemos.

Esa práctica nos sigue salvando hoy.