Caso · Konreservas
Reservas online, seguras desde la base.
Konreservas es un SaaS de reservas para cualquier negocio que trabaja con cita, en producción desde el 10 de noviembre de 2026. Es un producto propio de Bolmia y aquí se cuenta por dentro: cómo se reserva, cómo se entra, cómo se aísla cada negocio, cómo cobra y qué hace solo.
Tres superficies del mismo producto. Debajo, un solo núcleo.
Qué es
Un solo producto para cualquier negocio con cita.
Peluquerías, clínicas, fisios, pistas de pádel, academias, talleres o restaurantes: cada negocio configura su agenda, su cobro y sus avisos sobre el mismo núcleo, sin que el producto se parta en versiones.
Producto propio de Bolmia · SaaS de reservas online para negocios con cita · web y apps iOS y Android
De dónde sale
Un negocio que trabaja con cita —peluquerías, clínicas, fisios, pistas de pádel, academias, talleres, restaurantes…— vive entre el teléfono, la agenda y los que no se presentan. Konreservas se diseñó para todos ellos con dos exigencias desde el primer día: que cada negocio esté separado en la propia base de datos, no sólo en el código, y que cobrar no dependa de que todo salga bien.
Qué existe hoy
Un SaaS en producción desde el 10 de noviembre de 2026: web comercial en español e inglés, reserva pública embebible, panel del negocio, portal del cliente, administración de la plataforma y apps para iOS y Android. Cobra con Stripe o con el TPV del banco, avisa por correo, WhatsApp y push, y se entra con llave de acceso.
Qué se puede abrir
konreservas.com y sus 39 demos por sector, en las que se recorre la reserva entera sin cobrar ni enviar nada. Los paneles no: cada negocio tiene el suyo dentro de su cuenta.
- aplicaciones sobre un solo núcleo
- 8
- políticas de Row Level Security
- 69
- niveles de cerrojo con orden global
- 7
- pruebas automáticas
- +6.000
- migraciones de base de datos
- 66
- demos públicas por sector
- 39
La reserva
Sólo ofrece lo que de verdad está libre.
El cliente elige servicio, día y hora desde la web del negocio. Detrás hay un motor de disponibilidad escrito como función pura —intervalos, recurrencia y zonas horarias, sin tocar la base—, así que cada regla se prueba sola y la misma respuesta sale en la web, en el panel y en la app.
- Citas, clases con plazas, cursos completos, visitas a domicilio y mesas, en el mismo motor.
- El dinero, siempre en céntimos enteros: ni un decimal de coma flotante en todo el sistema.
- Widget embebible en cualquier web, con un tope de 500 KB vigilado por una prueba.
- Portal del cliente sin contraseña: escribe su correo y recibe un enlace para entrar.
- Enlace privado de calendario para ver la agenda en Google Calendar, Outlook o el iPhone.
- En español e inglés, de la web a los correos.
Seguridad
Se entra con una llave, no con una contraseña.
La contraseña existe, pero la entrada fuerte es una llave de acceso (passkey, el estándar WebAuthn): el dispositivo firma un reto con una clave privada que nunca sale de él. Sirven Windows Hello, Face ID, Touch ID o una llave física, en la web y en la app. Está probada y funcionando.
Así entra una llave de acceso
- NavegadorPide entrarNo hace falta escribir el correo: la llave es descubrible y el navegador ya sabe para qué cuenta es.
- ServidorLanza un retoUn reto aleatorio de un solo uso. En la base sólo queda su hash: robarla no sirve para responderlo.
- DispositivoFirmaFace ID, Touch ID, Windows Hello o la llave física comprueban a la persona y firman con la clave privada.
- ServidorVerificaFirma, origen y verificación de usuario obligatoria, comprobada en el servidor. Si falta una, no entra.
- ServidorAbre sesiónUn acceso de 15 minutos y un refresco que rota. Ni uno ni otro se guardan en claro.
No hay contraseña que robar ni código que copiar: la firma va atada a konreservas.com, así que una web que la imite no puede usarla.
La sesión
Un refresco robado se delata solo.
Los tokens son opacos, de 256 bits, y en la base sólo vive su SHA-256. Cada refresco rota de forma atómica: al usarse nace uno nuevo y el anterior muere. Si alguien presenta uno ya gastado, el sistema no adivina quién es el ladrón: revoca la familia entera.
- acceso · 15 minToken opaco de 256 bits; la sesión se relee de la base en cada petición.
- refresco R1 → R2Rotación atómica: R1 deja de valer en el mismo instante en que nace R2.
- R2 → R3La familia sigue viva mientras se use bien, hasta 30 días.
- R1 otra vezReutilización detectada: se revoca la familia entera y hay que volver a entrar.
- Segundo factorTOTP con protección contra repetición: un código ya usado no vale dos veces.
- RecuperaciónCódigos de 120 bits, guardados en SHA-256: ni la base los conoce.
- Secretos atadosLos secretos TOTP, cifrados con AES-256-GCM y atados a su dueño: copiar la fila a otra cuenta no descifra nada. Las credenciales de cobro usan otra clave.
- Contraseñasbcrypt con coste 12 y un hash señuelo: el tiempo de respuesta no revela qué cuentas existen.
- Dispositivos de confianza30 días —7 para superadmin— sin guardar la IP ni una huella del navegador.
- Política y refuerzoMFA en tres estados, superadmin obligado a una vía fuerte y una prueba fuerte reciente para cada acción sensible.
- Traspaso entre superficiesDel login al panel con un código de un solo uso: 256 bits, 60 segundos y Origin exacto. Sin URL de vuelta que manipular.
- Límites de peticionesPor red y por identidad, con almacén propio en PostgreSQL, para que nadie pruebe contraseñas a ciegas.
Las capas
Siete capas entre una petición y un dato.
Cada una funciona aunque falle la anterior. Las que importan no viven en el código de la aplicación, que se puede equivocar, sino en PostgreSQL, que no se salta sus propias reglas.
- 01Límite de peticionesAlmacén propio en PostgreSQL, por red —IPv6 agrupado en /56— y por identidad. Antes que nada.
- 02Sesión releídaCada petición vuelve a leer la sesión de la base: revocar una cuenta surte efecto en la petición siguiente.
- 03Rol sin privilegiosLa aplicación entra con un rol que no es superusuario, no tiene BYPASSRLS y no es dueño de las tablas.
- 04Row Level Security69 políticas con FORCE: un negocio no puede leer ni una fila de otro, aunque el código se equivoque.
- 05Cerrojos ordenadospg_advisory_xact_lock en 7 niveles con un orden global. Tomarlos fuera de orden falla en cualquier prueba, no sólo en una carrera real.
- 06Restricciones EXCLUDEGiST sobre tstzrange para profesional y recurso: la propia base rechaza dos reservas que se pisan.
- 07Libros de auditoríaDos, de sólo añadir. Si soporte entra como un negocio, entra en sólo lectura y queda escrito antes de responder.
Cómo está construido
Ocho aplicaciones, ocho paquetes y un solo núcleo.
Un monorepo donde cada superficie es su propia aplicación —con su despliegue y su política de seguridad— y todo lo que no puede divergir vive en paquetes compartidos: el motor, el dinero, los contratos de datos, la sesión.
Las apps
Una app nativa que no carga nada de un servidor.
La app de iOS y Android es el mismo panel React empaquetado con Capacitor 8 dentro de la propia app: no es una web metida en un marco. Cada entorno tiene su propio build, y el build se niega a salir si encuentra un fichero .map o una dirección de otro entorno.
El login nativo
- La app abre el navegador del sistema, no una vista web propia, con PKCE S256.
- Ahí se entra igual que en la web: contraseña, llave de acceso o segundo factor.
- Vuelve con un código de un solo uso. En iOS, con un plugin Swift propio sobre ASWebAuthenticationSession.
- El refresco se guarda cifrado en el Keychain o el Keystore, nunca en el almacenamiento web.
Los avisos push
- Entra una reserva, se cancela otra o se libera un hueco en la lista de espera.
- El aviso se encola dentro de la misma transacción: si la reserva no se guarda, el aviso no sale.
- El servidor habla directamente con APNs (HTTP/2, JWT ES256) y con FCM, sin SDK de terceros.
- Al tocarlo, la app abre esa reserva.
La app es para los negocios que usan Konreservas: se entra con la misma cuenta y la misma llave que en la web.
El cobro
El dinero nace en la cuenta del negocio.
Cada negocio cobra en lo suyo. Puede conectar su propia cuenta de Stripe o usar el TPV de su banco por Redsys, y pedir la señal que quiera: fija, un porcentaje o el pago completo, además de una fianza.
Automatización
Lo que el negocio ya no tiene que hacer a mano.
Desde que entra una reserva hasta después de la cita, Konreservas confirma, recuerda, avisa y pide la reseña solo. El cliente recibe correo y WhatsApp; el equipo, un aviso en el móvil.
Las pruebas
Cada garantía tiene una prueba que intenta romperla.
No basta con que las pruebas pasen. Konreservas tiene sabotajes propios: rompen el código a propósito, garantía por garantía, y exigen que alguna prueba lo note. Si nadie se entera, la garantía no está probada. Son 252 ficheros de prueba, y mientras corren la red está cerrada: nada sale de la máquina.
Hablemos
¿Necesitas un producto con este mismo rigor?
Konreservas es nuestro, y lo construimos igual que construimos los de nuestros clientes. Cuéntanos qué quieres poner en marcha y te decimos por dónde se empieza.