HomeSellers: Sitio de una correduría inmobiliaria con un motor de contenido y captación de clientes autogestionado

El problema

El sitio de una correduría suele fallar de una de dos formas. O es una plantilla genérica que se ve bien pero no puede captar ni encaminar un lead, o el negocio depende por completo de los portales de listados y no tiene una presencia que de verdad controle. En ambos casos se rompe lo mismo: el equipo no puede publicar nada sin llamar a un desarrollador, las consultas caen en una bandeja de entrada compartida sin estructura, y nadie puede decir qué página generó qué lead.

HomeSellers necesitaba un sitio que hiciera tres cosas a la vez: presentar la correduría como corresponde ante sus distintos públicos (residencial, comercial, inversionistas, mayoristas), captar y organizar cada lead, y dejar que el equipo gestione el contenido y el seguimiento sin un desarrollador de por medio.

Lo que construimos

Un sitio de marketing completo. Páginas dedicadas para cada público que atiende la correduría, más un blog y las páginas legales de siempre, todo sobre un frontend rápido y diseñado primero para móvil.

Captación de clientes en cada página. Cinco formularios separados, cada uno etiquetado con la página de la que vino, que escriben directo a una base de datos que la correduría posee. Cada consulta queda atribuida a su origen en lugar de desaparecer en una bandeja de entrada.

Un blog que el equipo maneja por su cuenta. Las notas se escriben y se publican desde el panel de administración y se sirven en URLs limpias. Sin desarrollador, sin despliegue, sin suscripción a un CMS.

Un panel de administración basado en roles. Los administradores gestionan leads, notas del blog y usuarios. Los editores están limitados solo al blog. Los leads avanzan por un flujo simple: nuevo, contactado, cerrado.

Autenticación e ingreso reforzados. Las contraseñas se guardan con hash (PBKDF2), las sesiones expiran en un horario fijo, los formularios tienen límite de solicitudes con una verificación opcional de bots, y el equipo recibe un correo en el momento en que entra un lead nuevo.

Cómo está construido

El frontend es un sitio estático en Cloudflare Pages, así que carga al instante en móvil, donde empieza casi toda búsqueda de bienes raíces. La API corre como Cloudflare Pages Functions contra una base de datos D1 (SQLite) que guarda leads, notas del blog, usuarios y sesiones. Las notificaciones de leads salen a través de un proveedor de correo transaccional.

Sin un stack de plugins de WordPress, sin suscripción a un creador de sitios, sin cuota mensual de plataforma más allá del dominio. La correduría es dueña del código, los datos y el flujo de publicación.

Lo que cambió

La correduría pasó de una presencia que no podía controlar a una que posee de principio a fin: un sitio rápido, formularios que registran y encaminan cada consulta por origen, y un blog que el equipo actualiza por su cuenta. Como cada lead queda atribuido a la página que lo generó, el equipo puede ver qué partes del sitio de verdad traen negocio en lugar de adivinar.

El stack

• Frontend: sitio estático en Cloudflare Pages
• API: Cloudflare Pages Functions
• Base de datos: Cloudflare D1 (SQLite): leads, notas, usuarios, sesiones
• Autenticación: hash de contraseñas con PBKDF2, tokens de sesión, acceso basado en roles (administrador / editor)
• Protección: límite de solicitudes, verificación opcional de bots, validación del lado del servidor
• Correo: notificaciones transaccionales de leads

Una correduría no necesita un creador de sitios con factura mensual y un proceso de publicación que no puede tocar. Necesita un sitio rápido que capte cada lead y un flujo de contenido que el equipo controla.