Génesis 11:6, from zero digital presence to a complete system in 48 hours

What was the problem?

Génesis 11:6 is a medical program led by Dr. David Chams with a 3-phase metabolic health protocol (initial detox, active weight loss, maintenance). After 17 years operating and treating hundreds of patients, the clinic was still invisible online: no website, no ranking on Google for searches like "metabolic health Barranquilla" or "medical weight loss program", and relied exclusively on word-of-mouth referrals.

Dr. Chams received inquiries via direct call, no prior filter, no qualification, no availability outside business hours, and a large share of those calls were repetitive questions his team could have resolved with standardized information. Real prospects were lost when nobody answered at 8 PM, or when the initial protocol explanation took longer than the team had available.

What did we consider before building?

We evaluated three paths: (1) a WordPress site with a generic chatbot plugin like Tidio or Drift; (2) a medical booking platform like Doctoralia or Agendapro; (3) building something custom.

WordPress + plugin would have been fastest but didn't solve the real problem, generic chatbots reply in English with rigid scripts that don't understand a 3-phase medical protocol. Booking platforms didn't fit either: Génesis isn't a quick-consultation clinic, it's a program that requires educating the prospect before the first appointment. The bot had to explain the protocol, filter suitable candidates (not everyone is eligible), and only then schedule.

We decided to build custom with a minimal stack: a fast static site, serverless Workers for the chatbots, and WhatsApp via API. No CMS, no own database, no layer to maintain long-term.

How did we design the solution?

The architecture splits into three pieces that talk to each other over HTTP but deploy independently:

1. Static website. A bilingual (Spanish/English) landing page explaining the 3-phase protocol, introducing Dr. Chams, showing real testimonials, and ending with a contact form. Built with Astro 5 + Tailwind v4 and deployed to Cloudflare Pages. No database, no backend, pure build-time HTML. Loads in under a second even on slow mobile connections.

2. Embedded web chatbot. A widget in the bottom-right corner that opens a conversation with an assistant trained specifically on the Génesis protocol. The widget calls a Cloudflare Worker that transforms each message into a request to Google Gemini 2.5 Flash (we picked Gemini for its ultra-low latency and marginal per-conversation cost), with a system prompt containing: (a) the full medical protocol as plain text, (b) strict safety rules ("never give personal medical advice, always redirect to consultation with Dr. Chams"), (c) a qualification flow that detects real intent and captures contact info.

3. 24/7 WhatsApp bot. A second Worker listens for webhooks from Evolution API (a self-hosted implementation of the WhatsApp API we deployed via Coolify on our own VPS, more economical than Meta's official API for medium volumes). When someone messages the Génesis WhatsApp number, Evolution API forwards the message to the Worker, the Worker calls Gemini with the same prompt as the website, and the reply returns to the user in seconds. The system prompt and safety rules are identical across both channels, one "brain" feeds two surfaces.

What stack did we use and why?

• Astro 5 + Tailwind v4, pre-rendered static site. Zero JavaScript on the client for the main content, which gives near-instant first load and a Lighthouse Performance score ≥95 without effort.
• Cloudflare Pages, global CDN hosting included, automatic deploys from GitHub, SSL, and caching. Monthly cost: $0 for current traffic.
• Cloudflare Workers, the chatbots are serverless Workers. They run on the edge closest to the user, scale to zero with no traffic, and bill per request. One Worker = one isolated process = easy to reason about.
• Google Gemini 2.5 Flash, chosen over Claude and GPT for latency (responses in <1.5s) and significantly lower per-message cost. Spanish quality is excellent, and structured JSON output for function calling simplifies lead capture.
• Evolution API, self-hosted implementation of WhatsApp Business API, deployed via Coolify. We chose this over Meta's official API because the volume didn't justify Meta's per-conversation fees and Evolution API allows multiple numbers at no extra cost.
• Coolify on our own VPS, a single machine hosts Evolution API and its database. Full control over where the client's data lives, no dependence on SaaS platforms that might change their pricing.

What results did we deliver?

The complete system was in production within 48 hours from our first conversation with Dr. Chams to final deployment. Concrete outcomes:

• Bilingual professional website at genesis116.com, indexed on Google
• 24/7 web chatbot that answers protocol questions, qualifies prospects, and captures contact info
• 24/7 WhatsApp bot connected to the same "brain" as the web chatbot, replying in seconds at any hour
• Explicit medical safety rules: the bot never diagnoses, never recommends doses, always redirects to consultation with Dr. Chams
• Operational monthly cost: essentially zero for current traffic (Cloudflare + Gemini tokens)

Most importantly: Génesis went from being invisible to search engines to having a system that automatically filters and qualifies leads, letting Dr. Chams spend his time on real patients, not explaining the same protocol over the phone ten times a day.

What did we learn?

Three lessons we've applied to similar projects since:

1. One brain, multiple channels. We wrote the system prompt once and reused it for both web and WhatsApp. That means when Dr. Chams wants to update how the bot explains phase 2 of the protocol, we change one file and both channels update simultaneously. Maintaining duplicated prompts is a trap we've seen in other projects, never again.

2. Workers are the "right" runtime for chatbots. You don't need a permanent server for a chatbot. A Worker that scales to zero with no traffic, runs on the edge, and bills per request is the architecture that should be default. It saves money, reduces latency, and eliminates an entire operations layer.

3. Safety rules go in the prompt, not in post-hoc filters. We first tried filtering "dangerous" responses post-hoc with a second LLM. It was complicated and slow. Writing the rules directly into the system prompt, "never give personal medical advice, always redirect to consultation", turned out to be more reliable and 10x faster. Modern models follow system instructions with high fidelity when they're well-written.