Clínica de larga estadía
De WordPress a aplicación de gestión
Diseñé y desarrollé la evolución del sitio de Clínica San Miguel a lo largo de sus distintas etapas. Hoy conecta la información pública y los formularios de consulta con un backend propio y un panel de seguimiento. La experiencia del visitante y las tareas del equipo se resuelven dentro del mismo proyecto.
Ver el sitioLa privacidad es lo primero
El tipo de datos definió el stack.
El proyecto maneja datos de categoría sensible. Eso impone un estándar distinto: menos herramientas, menos tránsito y menos superficie donde el dato pueda quedar expuesto.
El sitio dejó WordPress porque un CMS supone plugins, actualizaciones y código de terceros conviviendo con la información en el mismo servidor, y cada pieza añadida es una dependencia que hay que auditar. En HTML esa superficie desaparece: todo se resuelve con lo que el servidor ya corre, sin intermediarios. La base vive fuera del directorio público.
La medición sigue el mismo criterio y se ajusta a las políticas de Google y Meta sobre categorías sensibles: se mide el rendimiento de cada campaña, nunca información de la persona.
- HTML
- PHP
- SQLite
- JavaScript
- Apps Script
Tres hitos, tres tecnologías
El proyecto lleva años evolucionando para responder a lo que el negocio necesita en cada momento.
El sitio público
WordPress funcionaba bien. Se cambió porque el proyecto ya pedía tres cosas que un CMS genérico solo concede a medias: protección de datos, control y desempeño. Cada plugin y cada actualización es código ajeno corriendo en el mismo servidor donde vive la información. En HTML estático esa superficie no existe.
Sin plugins que actualizar, sin código externo que auditar y sin licencias que renovar. Control real sobre cada página, con navegación móvil con reglas propias, URLs limpias y SEO trabajado desde la estructura. Y un sitio mucho más liviano y rápido, que pesa en el posicionamiento y en la carga desde un celular.
La reescritura no buscaba solo un sitio mejor, sino una base sobre la que se pudiera construir.
Más control sobre la medición
Las campañas comenzaron en WordPress. La migración a HTML permitió controlar desde el código los clics en los botones, el envío de formularios y las páginas de confirmación, integrando Google Tag Manager, Google Ads y Meta Pixel. Cada canal tiene su propio recorrido: /cotiza para Google Ads y /cotiza-fb para Meta Ads, con dos landings, dos formularios y páginas de gracias diferentes. Así se identifica el origen de cada conversión sin depender de parámetros guardados en la URL o el navegador. Ambos recorridos comparten un handler PHP para validar, registrar y notificar las consultas.
Un envío claro para el visitante y trazable para el equipo
Los cuatro formularios ofrecen validación inmediata y envío asíncrono: el visitante puede corregir sus datos y recibir una respuesta sin que la página se bloquee. El servidor valida y registra la consulta, envía la confirmación al visitante y notifica al equipo para iniciar el seguimiento. En los formularios de campaña, el envío correcto conduce a la página de gracias del canal correspondiente, donde se mide la conversión. El registro adicional de marketing se realiza sin añadir espera al usuario. Si esa integración secundaria tarda o falla, la consulta permanece registrada y el recorrido principal puede completarse.
El panel que usa el equipo
A medida que aumentaron las consultas, el correo y las planillas siguieron sirviendo como registro, pero no mostraban con claridad el estado de cada caso ni qué gestiones estaban pendientes. El siguiente paso fue desarrollar un sistema de gestión a medida, integrado directamente al backend del sitio. Cada nueva consulta queda disponible de forma inmediata para su seguimiento, sin importaciones periódicas ni sincronizaciones manuales.
No todas las consultas requieren el mismo recorrido. Contacto general, admisiones y postulaciones laborales cuentan con etapas propias, mientras la bandeja prioriza solamente lo que necesita atención. Cuando un caso se cierra, se archiva: sale de la vista de trabajo, pero permanece disponible en el historial para conservar su trazabilidad.
Para comenzar sin perder el contexto acumulado, varios años de registros históricos distribuidos en distintas planillas fueron migrados con Python. El proceso normalizó formatos heterogéneos y los incorporó a una base estructurada mediante reglas reproducibles. La clasificación se apoyó en el origen verificable de cada registro, no en interpretaciones automáticas de su contenido, reduciendo errores y dejando una migración auditable.
Stack en evolución
Cada pieza entró en una etapa concreta y algunas cambiaron de función a medida que el sistema maduró. El criterio fue aumentar el control sin sumar una carga operativa que el proyecto no necesitaba.
| Tecnología | Por qué esa |
|---|---|
| HTML estático + Bootstrap 4 + jQuery 3.6 + vanilla JS | Despliegue directo en cPanel, sin build, conservando la interfaz existente y el control sobre cada interacción. |
| PHP nativo, sin Composer | Resuelve formularios, sesiones e integraciones con el runtime de cPanel, sin framework ni dependencias adicionales. |
| SQLite vía PDO | Aporta persistencia relacional y transacciones sin operar otro servidor de base de datos. |
Correo nativo de PHP (mail()) | Usa el correo del hosting; el registro previo protege la consulta si el envío falla. |
| Python para migración | Normalizó el historial con reglas reproducibles y quedó fuera de producción. |
| GTM + Google Ads + Meta Pixel | Separa las conversiones por flujo y entrega señales útiles para reportes y smart bidding. |
| Google Apps Script | Mantiene un registro paralelo para conciliar contactos del sistema con conversiones publicitarias. |
Lo que quedó en operación
14 páginas
Un sitio institucional que incluye dos landings de campaña con recorridos de conversión independientes.
4 formularios
Contacto general, postulación laboral, Google Ads y Meta Ads, con validación y confirmación automática.
Años de registros
El historial se incorporó a un sistema de seguimiento conectado directamente con los nuevos contactos.
8 documentos
Documentación técnica versionada sobre arquitectura, cambios, respaldo y restauración.