Cómo hacer una web de alquiler vacacional sin código
Para hacer una web de alquiler vacacional sin código, describe qué se alquila, qué hace que una fecha no esté disponible y qué ocurre después de reservar. Zugo genera el sitio con ese texto y una base de datos guarda las reservas de verdad. Una página de presentación sale en torno a un minuto.
La mayoría de webs de alojamiento nacen mal porque se describen pantallas en lugar de reglas. Un calendario bonito que no impide dos reservas en las mismas fechas es un problema con forma de solución, y se descubre en agosto.
¿Qué tiene que decidir tu web antes del diseño?
Tres preguntas, contestadas por escrito, determinan si esto es una tarde de trabajo o un proyecto pequeño. Conviene responderlas antes de abrir el generador.
¿Qué es la unidad reservable? Una casa entera, dos apartamentos, tres habitaciones dentro de la misma casa. No se comportan igual, y una web pensada para una unidad no se convierte sola en una web para tres.
¿Qué bloquea una fecha? Una reserva existente, la estancia mínima, el día de entrada permitido, el tiempo de limpieza entre huéspedes, las fechas que te reservas tú. Cada regla que no escribas se convierte en un mensaje de disculpa más adelante.
¿Qué pasa tras reservar? Confirmación por correo, señal, instrucciones de llegada, política de cancelación. Aquí es donde muchas webs se quedan cortas y acaban siendo un formulario que solo avisa por correo.
Con esas tres respuestas, el prompt casi se escribe solo, y sabrás si necesitas calendario real o basta con una solicitud de disponibilidad. Para un alojamiento con pocas reservas al mes, lo segundo funciona perfectamente.
¿Qué debe mostrar la ficha del alojamiento?
El huésped decide con datos concretos y fotos honestas, en ese orden. Faltar a cualquiera de los dos genera cancelaciones o reseñas malas, que cuestan más que un mes vacío.
| Bloque | Qué incluir | Error habitual |
|---|---|---|
| Capacidad | Plazas, camas por habitación, baños | Contar el sofá cama como plaza sin decirlo |
| Precio | Precio por noche por temporada, limpieza, fianza | Enseñar solo la noche base y sorprender al final |
| Reglas | Estancia mínima, entrada y salida, mascotas, fiestas | Dejarlas para el correo posterior a la reserva |
| Ubicación | Zona, distancias reales a playa, centro y súper | Decir "a un paso" sin dar minutos ni metros |
| Equipamiento | Wifi con velocidad, climatización, cocina, parking | Omitir lo que no hay, que es lo que se reclama |
| Fotos | Todas las estancias, en el mismo orden del recorrido | Cinco fotos del salón y ninguna del baño |
La dirección exacta se envía tras confirmar la reserva, no antes. En la ficha basta la zona y el mapa aproximado, y así lo espera cualquier huésped con experiencia.
Escribe las distancias en minutos andando y en metros. "Cerca de la playa" no significa nada y genera la peor de las decepciones el primer día.
¿Cómo se evita una doble reserva?
Este es el problema que la web existe para resolver, así que merece su propio párrafo en el prompt. Dilo con estas palabras: dos reservas que se solapen en las mismas fechas deben ser imposibles, y esa regla vive en la base de datos, no solo en la interfaz.
La distinción es real y cara. Un calendario que oculta las fechas ocupadas parece correcto y sigue permitiendo el solape, porque dos personas pueden cargar la página a la vez, ver el mismo hueco libre y enviar las dos. Quien decide es la base de datos, y solo si le pediste esa regla.
Pruébalo a propósito antes de publicar. Abre las mismas fechas en dos ventanas, envía las dos reservas con pocos segundos de diferencia y comprueba que después existe exactamente una y que la otra persona vio un mensaje claro. La lógica general de disponibilidad está desarrollada en la guía de sitios con reservas.
Conectando Supabase el sitio obtiene base de datos real, cuentas y almacenamiento, que es lo que convierte un calendario dibujado en un sistema en el que puedes confiar un puente de agosto.
¿Conviene cobrar la señal en la web?
Depende de tu volumen, y las dos respuestas son defendibles. Cobrar la señal en el momento elimina la mayoría de las reservas fantasma, pero añade un paso al flujo y obliga a definir la política de devolución antes de publicar.
Stripe cubre tanto los pagos únicos como las suscripciones, así que la señal en el momento de reservar o el pago completo por adelantado son ambos posibles. Lo que no se puede es decidirlo a medias: el prompt tiene que decir si la fecha se bloquea al pagar o al recibir la solicitud.
Resend se encarga de los correos, que en alquiler vacacional son parte del producto: confirmación, recordatorio unos días antes con las instrucciones de llegada, y mensaje de salida. Un alojamiento sin esos tres correos genera más llamadas de las que ahorra la web.
La parte de cobros está explicada con más detalle en si la IA puede hacer un sitio que cobre. Decide la política de cancelación antes de generar, porque condiciona el texto de toda la página.
Si dudas, empieza sin cobro en la web y con confirmación manual. Es más lento, pero te deja ver un mes de reservas reales antes de comprometerte con una política de devolución que después cuesta cambiar delante de un huésped enfadado.
¿Sustituye esto a los portales de reserva?
No, y plantearlo así lleva a decisiones malas. Los grandes portales aportan algo que una web propia no tiene: demanda constante de gente que no te conoce, además de sistemas de reseñas y de resolución de conflictos ya montados. Esa es una ventaja real y conviene reconocerla.
Lo que aporta tu web es margen y relación directa. El huésped que repite, el que te encontró en Instagram o el que recibió tu tarjeta en la casa puede reservar sin comisión de intermediación, y ese canal crece cada temporada si lo alimentas.
Una forma sencilla de alimentar ese canal es dejar la dirección de tu web escrita dentro de la casa, en la guía de bienvenida y en el imán de la nevera. El huésped que ya ha estado y quiere repetir busca primero por tu nombre, no por el portal.
La combinación habitual es tener ambos: los portales para llenar los huecos y la web propia para los repetidores y la temporada alta. Si haces eso, la sincronización de calendarios pasa a ser el punto delicado, y ahí conviene leer el apartado de límites de más abajo antes de prometer nada.
¿Cuánto cuesta montarla?
El plan gratuito da 5 créditos y sirve para ver la primera versión antes de pagar. Pro cuesta $25 al mes con 200 créditos e incluye dominio propio. Business son $99 al mes.
Las acciones tienen precio fijo: generar cuesta 6 créditos, editar cuesta 3 y un sitio de varias páginas se cobra como plataforma, 12 créditos por las tres primeras páginas y 3 por cada página adicional.
Un alojamiento único con ficha, disponibilidad y contacto son tres páginas: 12 créditos. Si añades zona, preguntas frecuentes y política de cancelación, son 9 créditos más. Cada retoque posterior, como cambiar los precios de temporada, son 3 créditos.
El modo Hi-Fi duplica ambas cifras, 12 la generación y 6 la edición, y aquí compensa en la ficha del alojamiento, porque las fotos y el precio son la decisión completa del huésped.
El sitio publicado queda en una dirección del tipo tucasa.zugo.run, que puedes enlazar hoy desde tu perfil o desde la tarjeta que dejas en la casa. El dominio propio se conecta después sin rehacer nada, y el código se exporta a GitHub si más adelante quieres continuarlo con un desarrollador.
¿Dónde se queda corto un generador de IA?
Cuatro límites que conviene tener claros.
No sincroniza calendarios con los portales. Mantener a la vez tu web y los portales sin solapes requiere una integración de calendarios propia. Mientras no la tengas, bloquea las fechas a mano y hazlo el mismo día, no el fin de semana.
Los precios dinámicos llegan por ediciones. Temporadas, mínimos por temporada, descuentos por estancia larga y recargos de último minuto se construyen paso a paso, no de un tirón.
No gestiona limpieza ni operativa. Avisar al equipo de limpieza, controlar inventario o coordinar llaves son procesos aparte.
Varios alojamientos con cuentas de propietario es otro producto. Un pequeño portal con varios dueños, pagos repartidos y reglas por unidad es el tipo de proyecto donde Zugo no sustituye a un equipo de desarrollo.
Para el caso normal, uno o dos alojamientos que necesitan una web propia con fotos, reglas claras y reservas que no se pisan, esto se resuelve en una tarde. Si tu caso es un establecimiento con recepción y varias habitaciones, la estructura es distinta y está en la guía de web de hotel. Empieza con los créditos gratuitos en zugo.dev.