01
Disponibilidad de verdad
Cada día muestra cuántas horas quedan y cada hora cuántas plazas. Lo que está completo se ve completo, no se descubre al final.
Demo interactiva · Turismo
Reservar una actividad sin pasar por WhatsApp.
La cara móvil de Slotly. El viajero elige la actividad, ve qué huecos quedan de verdad, ajusta cuántos son y reserva. El precio se recalcula al vuelo y sale un código de confirmación que el guía comprueba en el punto de encuentro.
Prueba a reservar el bautismo de surf: verás que el jueves hay más huecos y que las 16:00 están completas. Si se te queda pequeña, ábrela a pantalla completa.
TecnologíaReact Native + Expo
ParaOperadores turísticos
DatosEsquema real de Slotly
ReservaCódigo de confirmación
Por qué una app
La web vende. La app hace que vuelvan.
Slotly ya resuelve la venta desde el navegador. La app tiene sentido para lo que viene después: el cliente que repite en la misma semana, el que quiere consultar su código sin buscar el email, y el operador que quiere estar en la pantalla de inicio del móvil durante las vacaciones de alguien.
Por eso esta demo no intenta ser la web otra vez. Va directa a lo que se hace con el móvil en la mano.
02
Precio que se mueve contigo
El total se recalcula al cambiar el número de personas, y el botón de reservar lleva siempre el precio y la hora elegida encima.
03
Código de confirmación
Ocho caracteres en monoespaciada, sin letras que se confundan al dictarlas. Es lo que el guía comprueba en la playa.
Sobre los datos
Sigue el esquema real, no uno inventado.
Slotly corre sobre Postgres con tablas de experiencias, disponibilidad y reservas. La demo usa esa misma estructura —capacidad máxima, mínimo de participantes, horas de cancelación, código de confirmación— para que conectar la API sea sustituir el origen de los datos, no rehacer las pantallas.
Y no hay fotos. Cada actividad lleva una ilustración de degradado marcada como decorativa: poner fotos de sitios reales para un operador que no existe sería vender humo.
“La demo puede ser de mentira. La estructura de datos, mejor que no.”
Accesibilidad
El selector de personas, ese gran suspenso.
En casi todas las apps de reserva, el «− 2 +» son dos iconos sin nombre y un número que cambia sin que nadie se entere. Con lector de pantalla es un callejón sin salida: no sabes qué botón es cuál ni qué ha pasado al pulsarlo.
Cada botón dice qué hace
«Añadir una persona» y «Quitar una persona», no «más» y «menos». Y al pulsarlos se anuncia el resultado con el precio ya recalculado.
Los topes explican por qué
Al llegar al máximo, el botón se desactiva y dice que no quedan más plazas. Un botón gris sin explicación es una pared.
Los días y las horas se anuncian enteros
«Martes 18 de agosto, dos horas disponibles», no «18». Y «16:00, completo», no un texto tachado que el lector no menciona.
Los ajustes automáticos se dicen en voz alta
Si cambias a una hora con menos plazas y hay que bajar el número de personas, se avisa en lugar de cambiarlo por detrás.
Lo que aprendimos
Tres atributos que React Native no lleva a la web.
Construyendo las tres demos apareció el mismo problema una y otra vez: react-native-web pone bien los roles, pero no genera los atributos de estado. El resultado es una app que parece accesible en la revisión visual y no lo es con un lector de pantalla.
Se detecta midiendo el HTML que sale, no leyendo el código fuente.
| Lo que escribes | Lo que falta en web | Lo que hay que pasar |
|---|---|---|
accessibilityState={{checked}} | El lector nunca dice «seleccionado» | aria-checked |
accessibilityState={{disabled}} | El botón parece pulsable | aria-disabled |
accessibilityElementsHidden | Se leen los emojis decorativos | aria-hidden |
En los tres casos la solución es la misma y sirve para las tres plataformas: pasar el atributo ARIA directamente, porque React Native lo traduce de vuelta a accessibilityState en iOS y Android.
Cómo está hecha
Misma base de código, tres destinos.
React Native con Expo, como las otras dos demos. De aquí sale el paquete de las tiendas y esta versión web con HTML real, que es la que estás tocando.
React Native
Expo SDK 57
Expo Router
TypeScript
expo-linear-gradient
Export estático
Qué es y qué no
Hasta dónde llega esta demo.
Es una maqueta funcional, no una pasarela de reservas
El operador es ficticio, no se cobra nada, no se envía ningún correo y las reservas viven en la memoria del navegador. Para conectarla a Slotly de verdad haría falta:
- La API de Slotly como origen de experiencias y disponibilidad
- Pago con Stripe y reparto entre plataforma y operador
- Bloqueo de plaza mientras dura el proceso de pago
- Cuenta del viajero para ver y cancelar sus reservas
- Notificaciones push el día antes de la actividad
- Traducción, porque aquí el cliente llega en cuatro idiomas
¿Tienes un producto web y te falta la parte móvil?
Cuéntame qué hace hoy tu plataforma y qué querrías que la gente pudiera hacer desde el móvil. Te digo qué merece la pena llevar a una app, qué es mejor dejar en la web y con qué alcance empezar.