Equipo RestaPro

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.

Después de las entrevistas tocaba decidir el alcance. Y la decisión más difícil de un producto nuevo no es lo que va a hacer; es lo que no va a hacer. Lo escribimos en una hoja a tres columnas: "sí", "todavía no" y "nunca".

La columna del "nunca" fue la que más discusiones generó. Pero nos ayudó a ahorrar meses.

Antes de programar nada, nos pusimos un límite: 30 entrevistas con hosteleros antes de abrir el editor. Tabernas, asadores, cafeterías, un par de cocinas de autor, una franquicia de tres locales. Ningún cuestionario rígido; café, libreta y dos preguntas iniciales: "¿Qué herramienta usas hoy?" y "¿Qué te saca de quicio cada semana?".

Pensábamos que íbamos a salir con una lista enorme y dispersa. Salimos con tres frases que se repetían casi palabra por palabra.

A mediados de 2025 nos sentamos a darle vueltas a una pregunta incómoda: ¿de verdad hace falta otra herramienta para restaurantes? El mercado parece saturado. Hay reservas, hay TPV, hay programas de fidelización. Y aun así, cada vez que entrábamos en una cocina o detrás de una barra, pasaba lo mismo: la pantalla que tenía el encargado parecía sacada de 2010.

Llevamos ocho años haciendo SaaS para otros sectores. La pareja del fundador regenta un restaurante en el centro, así que el banco de pruebas estaba puesto. La conclusión, después de muchas conversaciones de sobremesa, fue que merecía la pena intentarlo.