Cómo crear un sitio de reservas sin escribir código
Un sitio de reservas sin código empieza decidiendo qué reservas de verdad: una solicitud que confirmas tú o un hueco que se bloquea al instante. En Zugo la primera versión es una construcción de 6 créditos y algo más de un minuto, y la segunda requiere base de datos detrás.
Esa distinción decide el proyecto entero, el presupuesto y el mantenimiento. La mayoría de negocios pequeños necesita la versión de solicitud, y monta la otra por costumbre.
¿Qué es exactamente un sitio de reservas?
Bajo el mismo nombre conviven dos productos muy distintos. Uno recoge una petición: fecha deseada, servicio, datos de contacto, y tú confirmas por teléfono o correo. El otro gestiona disponibilidad real: sabe qué huecos existen, los bloquea al reservar y evita que dos personas cojan el mismo.
El primero se construye en una tarde y funciona bien hasta un volumen sorprendentemente alto. El segundo es software con reglas: duración de cada servicio, descansos, festivos, cancelaciones, recordatorios y qué pasa cuando alguien no aparece.
La pregunta que separa los dos casos es simple: ¿pierdes dinero si dos personas piden la misma hora? Si la respuesta es no, porque llamas y lo mueves, la solicitud basta. Si la respuesta es sí, porque hay una sala, un coche o un asiento físico, necesitas disponibilidad real.
Hay un tercer camino que casi nadie considera y que suele ganar: enlazar a la herramienta de reservas que ya usas y dedicar la web a lo que esa herramienta hace mal, que es explicar el servicio y dar confianza.
¿Solicitud o reserva con pago?
Cuatro configuraciones cubren casi todos los casos. La diferencia principal no es el aspecto de la página, es lo que ocurre después de pulsar el botón.
| Modelo | Qué conectas | A quién le encaja | Riesgo principal |
|---|---|---|---|
| Formulario de solicitud | Resend para el correo | Servicios que se presupuestan o se ajustan | Responder tarde y perder la reserva |
| Solicitud con calendario visible | Nada, el horario es informativo | Negocios con horario estable | El cliente cree que el hueco está confirmado |
| Reserva con disponibilidad real | Supabase para huecos y reservas | Salas, coches, plazas limitadas | Doble reserva si la lógica falla |
| Reserva con pago o señal | Supabase y Stripe | Actividades con ausencias frecuentes | Devoluciones y condiciones mal escritas |
La señal cambia el comportamiento más que ninguna función. Si tu problema real es que la gente reserva y no aparece, cobrar una parte por adelantado resuelve más que cualquier recordatorio automático.
Antes de subir un escalón, comprueba si el anterior falla de verdad. Muchos negocios montan disponibilidad real para diez reservas semanales que se gestionaban perfectamente por correo.
¿Qué prompt describe un sitio de reservas?
Describe el servicio, la duración, las reglas y qué ocurre tras enviar el formulario. Las reglas que no escribas se las inventará el generador, y en reservas una regla inventada es una promesa que tú tendrás que cumplir.
Construye un sitio de reservas para [tipo de negocio].
Páginas:
1. Inicio: qué se reserva, precio desde, botón "Reservar" visible
también al hacer scroll en móvil.
2. Servicios: [lista con nombre, duración y precio].
3. Reservar: formulario con servicio, fecha, franja horaria,
nombre, teléfono y correo, más una casilla de condiciones.
4. Condiciones: antelación mínima, política de cancelación y qué
pasa si el cliente no aparece.
5. Contacto y ubicación: dirección, mapa y horario día por día.
Al enviar: mensaje claro de "solicitud recibida, confirmamos en
[X] horas" y copia por correo al negocio y al cliente.
Idioma español.
La frase del final es la que evita la mitad de las llamadas. Un formulario que solo dice "gracias" deja al cliente sin saber si tiene hora, y esa duda acaba en el teléfono o en una reserva paralela en otro sitio.
Zugo incluye 25 plantillas listas, y partir de una de servicios locales acorta el camino cuando la estructura ya se parece a la tuya.
¿Qué hace falta detrás: base de datos y correos?
Dos piezas, y conviene entender qué aporta cada una.
Correo. Con Resend conectado, cada solicitud llega a tu bandeja y el cliente recibe copia. Es lo mínimo imprescindible: un formulario que guarda en algún sitio que nadie mira equivale a no tener formulario.
Base de datos. Con Supabase, las reservas se guardan como filas, se consultan y se pueden marcar como confirmadas. También sirve para cuentas de cliente si quieres que la gente vea su historial. Cómo se monta está en la guía de aplicaciones con Supabase.
Pagos. Stripe cobra la señal o el importe completo, y también suscripciones si vendes bonos. Cobrar por adelantado exige condiciones de cancelación escritas antes, no después del primer conflicto.
Un detalle práctico: guarda siempre la reserva en la base antes de intentar el cobro. Si el pago falla y no has guardado nada, pierdes el contacto de alguien que quería reservar, y esa es la peor forma posible de perder un cliente.
¿Cuánto cuesta construirlo?
Una página de reservas simple con formulario cuesta 6 créditos. Un sitio con servicios, reservas, condiciones y contacto en páginas propias es una plataforma multipágina: 12 créditos por las tres primeras páginas y 3 por cada página adicional.
El plan gratuito da 5 créditos, que no llegan a una construcción completa. Pro cuesta $25 al mes con 200 créditos, suficiente para montar el sitio y ajustarlo durante meses. Business cuesta $99 al mes.
Cada edición cuesta 3 créditos, y en un sitio de reservas se editan bastantes cosas: precios, franjas, condiciones de cancelación, festivos. Cuenta con un puñado de ediciones en la primera semana, cuando aparecen los casos que no habías previsto.
El modo Hi-Fi duplica ambas cifras, 12 al construir y 6 al editar. Para un sitio de reservas rara vez compensa, porque lo que convierte es la claridad de las condiciones, no el acabado visual.
¿Cómo se prueba antes de publicar?
Cada construcción se arranca en un entorno aislado antes de entregarse, y la que no abre se reporta como fallo en lugar de llegar como página en blanco. Eso descarta lo obviamente roto, no valida tus reglas de negocio.
Haz cuatro pruebas manuales. Envía una reserva completa y comprueba que el correo llega a las dos partes. Envía una con el teléfono vacío y mira si el formulario avisa. Prueba una fecha pasada y confirma que se rechaza.
La cuarta prueba es la que más gente salta: hazlo todo desde el móvil, con una mano, como lo hará el cliente. La mayoría de fallos de un formulario de reservas no son errores de código, son campos incómodos en una pantalla pequeña.
Después conecta la analítica para saber cuántos empiezan el formulario y cuántos lo terminan. Esa diferencia es el único número que de verdad mide si tu sitio de reservas funciona.
¿Dónde se detiene un constructor con IA?
Cuatro límites, dichos claramente.
La disponibilidad real es un proyecto. Bloquear huecos, gestionar solapamientos y evitar dobles reservas exige lógica y pruebas. Se construye con base de datos, pero se afina con ediciones sucesivas, no con un prompt.
Los recordatorios automáticos necesitan una pieza más. Enviar un aviso la víspera implica algo que se ejecute solo cada día. Es posible, pero deja de ser una web y pasa a ser un pequeño sistema.
No sustituye a un equipo de desarrollo. Si el negocio depende del calendario, con varios recursos y reglas complicadas, en algún momento necesitas gente. La exportación a GitHub entrega el código y el proyecto es tuyo, así que empezar aquí no cierra puertas.
Las condiciones legales son tuyas. Cancelaciones, devoluciones y datos personales tienen normas que dependen de tu país. La web las publica, no las redacta por ti.
Para el caso más común, un negocio que quiere recibir peticiones ordenadas en vez de mensajes sueltos, esto se resuelve en una tarde. Si tu caso es un negocio de servicio con cita corta, la guía de barberías sin código muestra la versión ligera. Empieza describiendo tus reglas en zugo.dev.