Qomanda

Qomanda no compite por comisión, compite por claridad: 49 € al mes por restaurante (IVA aparte), escrito. En la home, en la página de precios y en la comparativa. Sin «solicita presupuesto», sin comercial de por medio, sin permanencia, con treinta días de prueba y sin tarjeta. Un precio publicado es un precio que te obliga a que el producto lo valga.

Y el comensal es del restaurante. El motor de reservas se incrusta en la web del propio local con un iframe, en doce idiomas con autodetección: la reserva entra por su dominio, con su marca y sus colores. Detrás, un back-office para la sala —la vista Día, con la lista del servicio, el plano en vivo y el cronograma mirando la misma reserva, más CRM y analítica. Todo sobre Next.js 16 y React 19, con Supabase por debajo: 42 tablas y las 42 con seguridad a nivel de fila, de modo que el aislamiento entre restaurantes no depende de que la aplicación se acuerde de aplicarlo.

Una reserva puede estar en quince estados distintos, porque una sala real no cabe en «confirmada» y «cancelada»: hay llegada, llegada en barra, sentada, postre, cuenta solicitada, limpiar. Y los catorce alérgenos de la lista europea van en la ficha del comensal, porque en un producto así una alergia mal leída no es una cuestión de gusto.

La web de marketing, por cierto, nació oscura y acabó migrando al mismo lenguaje visual claro que ya usaba la aplicación. El documento que rige esa migración mapea cada color por el papel que cumple —fondo, borde, acento— y no por su tono, para que nada se rompa al cambiar de familia. Y las capturas que se ven en la web son la aplicación real, no un montaje.

Reservas es la primera pieza, no la única. Encima ya está construido el módulo de comandas y TPV —comanda por QR, pantalla de cocina, escandallo, stock y facturación encadenada— que hoy se concede caso a caso: un TPV que emite facturas no es algo que deba encenderse solo con un interruptor, y hace falta que Alture otorgue el derecho en la propia base de datos además de que el restaurante lo active.

La dirección es esa: un ecosistema completo para la sala, todo sobre el mismo dato y bajo el mismo panel, en lugar de cuatro herramientas de cuatro proveedores que no se hablan entre ellas.

Un software de reservas se juzga por lo que hace cuando nadie mira.

El aforo lo decide la base de datos, no la aplicación. Una sola función SQL toma un bloqueo por restaurante y fecha, revisa aforo y mesa e inserta la reserva dentro de la misma transacción, con un disparador encima que rechaza cualquier solape aunque la reserva entre por otro camino. Dos comensales que pulsen a la vez no pueden ocupar el mismo hueco, y no porque la aplicación se acuerde de comprobarlo: porque la base no deja.

El dinero de las fianzas no pasa por nosotros. Las garantías contra el no-show van por Stripe Connect con cargos directos: la cuenta es del restaurante y el cobro cae en su balance. Qomanda no retiene fondos en ningún momento.

Silencio no es éxito. Cada tarea programada estampa un latido y un vigilante horario avisa si alguna se calla. Importa porque unos recordatorios que dejan de salir no producen ningún error visible: producen no-shows, y de eso te enteras el sábado por la noche.

Un impago no secuestra los datos. Las exportaciones de reservas, clientes y facturas están a propósito fuera del muro de pago, y el motor público sigue aceptando reservas catorce días después de que caduque la suscripción: un cobro fallido no puede cortarle las reservas a un restaurante en silencio.

El panel no se indexa; el motor sí. La web de marketing publica veintiuna rutas por idioma, español e inglés, cada una con su canonical propio y su hreflang, y las comparativas citan sus fuentes con enlace y fecha. El back-office, en cambio, va bloqueado entero a los buscadores, mientras que el motor de reservas de cada restaurante se indexa con sus datos estructurados. Son cosas distintas y se tratan como tales.

Y una regla de interfaz que es de Alture antes que de Qomanda: en el panel no hay un solo visto verde que no gobierne algo de verdad. Lo que está por llegar se marca «Próximamente», y hay una pieza del sistema de diseño hecha solo para eso.

Construir producto propio obliga a algo que un encargo no obliga: a vivir dentro de tus decisiones. Cuando la herramienta que recomiendas es la tuya, dejas de diseñar pantallas y empiezas a diseñar cosas que aguanten un sábado a las nueve y media.

Y eso es exactamente lo que se lleva quien nos encarga una aplicación: no una agencia que ha leído sobre multi-tenencia, cobros recurrentes o aislamiento de datos, sino una que los tiene funcionando en producción, con su propio nombre en la factura.