Si ya tienes tu carta colgada en una página propia o en Google Business, RestaPro puede tirar de ahí en lugar de obligarte a escribirla otra vez.

Lote de "ergonomía y cumplimiento": si vas a darle acceso a tu encargado o jefa de sala, ahora es un click. Y si te lo piden tus asesores, ya tienes página legal pública.

Hoy publicamos la primera versión de RestaPro. Es la culminación de meses pensando cómo debería ser una herramienta de gestión para hostelería que no te haga sentir que peleas contra ella.

A finales de febrero teníamos una beta funcionando bien con ocho restaurantes y una decisión tomada: el 19 de marzo abrimos al público. Eso nos dejaba unas dos semanas y media. Se sienten cortas. Y, efectivamente, lo fueron.

No queríamos lanzar a lo grande con bombo y platillo. Queríamos lanzar tranquilo: que cualquier hostelero pudiera entrar, registrarse, pagar y empezar a trabajar sin sorpresas. Suena modesto. Implica una lista de tareas larga.

En enero pasamos de tres amigos a ocho restaurantes. La elección no fue al azar: queríamos variedad. Una asadora castellana, dos cafeterías de barrio, un grupo con dos locales de cocina mediterránea, una hamburguesería, un japonés y una taberna con mucha barra. Tipologías muy distintas a propósito. Si funcionaba para los ocho, funcionaba para casi cualquiera.

El trato fue claro y por escrito: pagáis 0€ durante la beta. A cambio nos decís lo que falla, y nosotros lo arreglamos en 48 horas o explicamos por qué no podemos.

A mediados de diciembre llegó el primer momento de la verdad: enseñarle el producto a hosteleros reales, no a familiares amables que dicen que está muy bonito. Elegimos a tres dueños de restaurante que ya conocíamos del proceso de entrevistas, dispuestos a ensuciarse las manos. Les dimos acceso, una promesa de bug fixes en horas y una botella de vino por las molestias.

Una semana después teníamos la libreta llena de cosas que arreglar. La sensación fue la misma que se tiene siempre con los primeros usuarios: te das cuenta de que muchas cosas que dabas por evidentes no lo eran.

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.

Una de las primeras cosas que vimos en las entrevistas fue que muchas operaciones tienen más de un local. No hablamos solo de cadenas grandes; hablamos de un grupo familiar con dos asadores y una cervecería, o de una franquicia pequeña con tres locales en la misma ciudad. Si el software te obliga a crear una cuenta por sitio y reescribir los datos cada vez, te sale gratis odiarlo.

Por eso, en octubre, dedicamos un par de semanas a un tema que parece interno y aburrido pero que define el techo del producto: cómo modelamos los datos.

En septiembre llegó el momento de elegir tecnología. Es una conversación que en muchos proyectos dura meses; nosotros la quisimos cerrar en una semana. La pregunta no era "¿qué stack es el mejor?" sino "¿qué stack nos permite ir rápido siendo dos personas y dormir tranquilos en producción?".

La respuesta corta: Supabase y nada más para empezar. Sin servidores propios, sin Kubernetes, sin Java. La respuesta larga es esta entrada.

Llegado agosto tocaba dejar de teorizar y empezar a poner colores. El sistema de diseño es de esas cosas que parecen menores hasta que las tocas: si te equivocas, lo arrastras durante años. Así que nos sentamos con un par de diseñadores y dedicamos casi tres semanas a algo que en el plan original era "una tarde".

La pregunta que más nos hicieron amigos del sector fue: ¿por qué un azul vibrante en lugar del rojo terracota o el verde oliva que se ve siempre en hostelería? Va por partes.