Génesis 11:6, de cero presencia digital a sistema completo en 48 horas

¿Cuál era el problema?

Génesis 11:6 es un programa médico liderado por el Dr. David Chams con un protocolo de salud metabólica de 3 fases (detox inicial, pérdida activa, mantenimiento). Tras 17 años operando y tratando a cientos de pacientes, la clínica seguía siendo invisible en línea: no tenía página web, no aparecía en Google para búsquedas como "salud metabólica Barranquilla" o "programa de pérdida de peso médico", y dependía exclusivamente de referidos boca a boca.

El Dr. Chams recibía consultas por llamada directa, sin filtro previo, sin calificación, sin disponibilidad fuera de horario, y un porcentaje alto de esas llamadas eran preguntas repetitivas que su equipo podía haber resuelto con información estandarizada. Los prospectos reales se perdían cuando nadie contestaba a las 8pm, o cuando la explicación inicial del protocolo tomaba más tiempo del que el equipo tenía disponible.

¿Qué consideramos antes de construir?

Evaluamos tres rutas: (1) un sitio WordPress con un plugin de chatbot genérico tipo Tidio o Drift; (2) una plataforma de reservas para consultorios médicos como Doctoralia o Agendapro; (3) construir algo a medida.

WordPress + plugin habría sido lo más rápido pero no resolvía el problema real, los chatbots genéricos responden en inglés con scripts rígidos que no entienden un protocolo médico de 3 fases. Las plataformas de reservas tampoco encajaban: Génesis no es una clínica de consulta rápida, es un programa que requiere educación del prospecto antes de la primera cita. El bot tenía que explicar el protocolo, filtrar candidatos apropiados (no todos son aptos) y solo entonces agendar.

Decidimos construir a medida con un stack mínimo: sitio estático rápido, chatbots como Workers sin servidor, y WhatsApp vía API. Sin CMS, sin base de datos propia, sin capa que mantener a largo plazo.

¿Cómo diseñamos la solución?

La arquitectura se divide en tres piezas que se comunican entre sí por HTTP pero se despliegan de forma independiente:

1. Sitio web estático. Una landing page bilingüe (español/inglés) que explica el protocolo de 3 fases, presenta al Dr. Chams, muestra testimonios reales y termina con un formulario de contacto. Construido con Astro 5 + Tailwind v4 y desplegado en Cloudflare Pages. Sin base de datos, sin backend, puro HTML generado en build time. Carga en menos de un segundo incluso en conexiones móviles lentas.

2. Chatbot web embebido. Un widget en la esquina inferior derecha de la página que abre una conversación con un asistente entrenado específicamente en el protocolo Génesis. El widget llama a un Cloudflare Worker que transforma cada mensaje en una petición a Google Gemini 2.5 Flash (elegimos Gemini por su latencia ultra-baja y su costo marginal por conversación), con un prompt de sistema que contiene: (a) el protocolo médico completo en texto plano, (b) reglas de seguridad estrictas ("nunca dar consejos médicos personales, siempre redirigir a consulta con el Dr. Chams"), (c) un flujo de calificación que detecta intención real y captura contacto.

3. Bot de WhatsApp 24/7. Un segundo Worker escucha webhooks de Evolution API (una implementación self-hosted de la WhatsApp API que desplegamos vía Coolify en un VPS propio, más económico que la API oficial de Meta para volúmenes medios). Cuando alguien le escribe al número de WhatsApp de Génesis, Evolution API envía el mensaje al Worker, el Worker llama a Gemini con el mismo prompt del sitio web, y la respuesta regresa al usuario en segundos. El prompt de sistema y las reglas de seguridad son idénticas en ambos canales, un solo "cerebro" alimenta dos superficies.

¿Qué stack técnico usamos y por qué?

• Astro 5 + Tailwind v4, sitio estático pre-renderizado. Cero JavaScript en el cliente para el contenido principal, lo que da una primera carga casi instantánea y un Lighthouse Performance score ≥95 sin esfuerzo.
• Cloudflare Pages, hosting global con CDN incluido, deploy automático desde GitHub, SSL, y cache. Costo mensual: $0 para el tráfico actual.
• Cloudflare Workers, los chatbots son Workers sin servidor. Se ejecutan en el edge más cercano al usuario, escalan a cero cuando no hay tráfico, y facturan por petición. Un Worker = un proceso totalmente aislado = fácil de razonar.
• Google Gemini 2.5 Flash, escogido sobre Claude y GPT por latencia (respuestas en <1.5s) y costo por mensaje significativamente más bajo. La calidad en español es excelente, y el formato JSON estructurado para función calling simplifica la captura de leads.
• Evolution API, implementación self-hosted de WhatsApp Business API, desplegada vía Coolify. Elegimos esta ruta sobre la API oficial de Meta porque el volumen no justificaba las tarifas por conversación de Meta y Evolution API permite múltiples números sin costo adicional.
• Coolify sobre VPS propio, una sola máquina aloja Evolution API y su base de datos. Control total sobre dónde viven los datos del cliente, sin depender de plataformas SaaS que puedan cambiar sus precios.

¿Qué resultados entregamos?

El sistema completo estaba en producción en 48 horas desde la primera conversación con el Dr. Chams hasta el despliegue final. Resultados concretos:

• Sitio web profesional bilingüe en genesis116.com, indexado en Google
• Chatbot web 24/7 que responde preguntas sobre el protocolo, califica prospectos y captura contacto
• Bot de WhatsApp 24/7 conectado al mismo "cerebro" del chatbot web, contestando en segundos a cualquier hora
• Reglas de seguridad médica explícitas: el bot nunca diagnostica, nunca recomienda dosis, siempre redirige a consulta con el Dr. Chams
• Costo operativo mensual: prácticamente cero para el tráfico actual (Cloudflare + tokens de Gemini)

Lo más importante: Génesis pasó de ser invisible para buscadores a tener un sistema que filtra y califica leads automáticamente, permitiendo que el Dr. Chams dedique su tiempo a pacientes reales, no a explicar el mismo protocolo por teléfono diez veces al día.

¿Qué aprendimos?

Tres lecciones que aplicamos a proyectos similares desde entonces:

1. Un solo cerebro, múltiples canales. Escribimos el prompt de sistema una vez y lo reutilizamos en web y WhatsApp. Esto significa que cuando el Dr. Chams quiere actualizar cómo el bot explica la fase 2 del protocolo, cambiamos un archivo y los dos canales se actualizan simultáneamente. Mantener prompts duplicados es una trampa que vimos en otros proyectos, nunca más.

2. Workers como runtime "correcto" para chatbots. No necesitas un servidor permanente para un chatbot. Un Worker que escala a cero cuando no hay tráfico, se ejecuta en el edge, y factura por petición es la arquitectura que debería ser default. Ahorra dinero, reduce latencia y elimina toda una capa de operaciones.

3. Las reglas de seguridad van en el prompt, no en filtros posteriores. Intentamos primero filtrar respuestas "peligrosas" post-hoc con otro LLM. Fue complicado y lento. Escribir las reglas directamente en el prompt de sistema, "nunca dar consejos médicos personales, siempre redirigir a consulta", resultó ser más confiable y 10 veces más rápido. Los modelos modernos respetan instrucciones del sistema con alta fidelidad cuando están bien escritas.