El encargo

El negocio revende experiencias acuáticas en Miami —jet ski, ATV y yates— con su propio margen. El tráfico llega por Instagram, pero no había a dónde mandarlo: ni web, ni dominio, ni forma de reservar más allá de los DMs. La competencia, en cambio, ya aparecía en Google con sitios montados y reservas en línea.

Había dos restricciones de negocio que terminaron siendo decisiones de ingeniería: la dueña revende con markup (cobra ella y le paga al operador), y le aterran los chargebacks de tarjetas robadas. Cualquier solución tenía que respetar ambas cosas, no solo "verse bonita".

La decisión: a medida, no plantilla

El camino fácil habría sido un Wix genérico. Lo descartamos por una razón concreta: una plantilla idéntica a la de mil negocios no transmite confianza, y —peor— deja a la dueña sin poder editar nada sin pagar por cada cambio. Para un catálogo que cambia de precios y fotos seguido, eso envejece en semanas.

La alternativa fue construir un front-end a medida y separar el contenido del código. La dueña no debería tocar HTML para subir un tour nuevo; debería hacerlo desde una interfaz tan simple como una hoja de cálculo. Eso apunta directo a una arquitectura headless.

La arquitectura

El sistema completo son cuatro piezas, todas en planes gratuitos o de bajo costo, sin servidor que mantener.

1. Front-end estático a medida

Una página de una sola pantalla, mobile-first (el tráfico viene de Instagram), con su marca y su dominio propio con SSL. Hospedaje en CDN: rápida en cualquier parte y sin nada que parchear.

2. Airtable como CMS headless

El catálogo —nombre, descripción, precio, depósito, fotos, activo/inactivo— vive en una base de Airtable. Para la dueña es una hoja con fotos que edita desde el celular. Para el sistema, es la fuente de verdad del contenido. Sube un tour, cambia un precio, y el sitio lo refleja sin tocar código ni volver a desplegar.

3. Una función serverless de por medio

El sitio no habla con Airtable directamente: lo hace a través de una función serverless. ¿Por qué? Porque el token de la API jamás puede vivir en el código del navegador, donde cualquiera lo leería. La función corre del lado del servidor, guarda el token en variables de entorno y le entrega al front solo lo que necesita, ya limpio. Seguridad por diseño, no por suerte.

4. Galería dinámica y reservas por WhatsApp

Cada producto abre una ficha con galería deslizable y lightbox a pantalla completa — la experiencia de una marca grande. El botón de reservar abre WhatsApp con el pedido ya redactado: el cliente confirma en dos toques, sin formularios ni fricción.

El detalle que importa

El contenido no se "incrusta" en la página: se carga en vivo desde Airtable en cada visita. La dueña es dueña de su catálogo. Nosotros operamos la tubería por debajo — y si algo se cae, hay un respaldo estático para que la página nunca quede vacía.

Ingeniería del cobro (el problema real)

Aquí es donde un diseñador para y un ingeniero sigue. El miedo a los chargebacks no se resuelve con CSS: se resuelve con el flujo de dinero.

El modelo que montamos: el cliente paga un depósito con tarjeta equivalente al margen de la dueña, y el saldo en efectivo el día del tour, directo al operador. El efectivo no se puede reclamar al banco, así que la exposición a fraude se reduce a la parte chica — y la dueña nunca cobra dinero que no es suyo. Es una regla de negocio implementada como lógica de producto, no un adorno.

El resultado

El negocio pasó de no existir online a tener miabluecharters.com: dominio propio, SSL, catálogo con fotos reales, galería profesional, WhatsApp para reservar y un panel que la dueña edita sola. El grueso del montaje fue cuestión de una tarde — porque la arquitectura es simple a propósito, no porque se haya recortado.

Lo que demuestra este caso no es "hacemos webs baratas". Es que la misma forma de pensar que usamos para productos SaaS en producción —separar contenido de código, esconder los secretos, dejar el dato como fuente de verdad— aplica igual de bien a un negocio de jet skis. La diferencia entre una plantilla y esto no se ve el primer día; se ve a los seis meses, cuando la dueña sigue editando su web sola y la plantilla del vecino quedó congelada.