Volver a Proyectos

📋 Seguimiento CAS

PWA de seguimiento comercial inmobiliario con plantillas de contacto y funcionamiento offline

PWA instalable Auth por token Plantillas de mensaje

Escala del Proyecto

8Tablas
9Endpoints
17Archivos
3.3kLíneas

Descripción General

El trabajo comercial de una inmobiliaria se pierde en el seguimiento. Contactar con un propietario una vez es fácil; recordar que hay que volver a llamarle en dos semanas, y saber qué se le dijo la última vez, es lo que se olvida. Y lo que se olvida no se cierra.

Seguimiento CAS es una PWA pensada para usarse desde el móvil durante la jornada: registra propietarios, inquilinos, compradores, propiedades y visitas, y mantiene el estado de seguimiento de cada contacto con su agenda de próximos pasos.

Para no reescribir el mismo mensaje veinte veces, incluye plantillas reutilizables. Y como se usa en la calle, funciona instalada en la pantalla de inicio y con soporte offline mediante service worker.

Tecnologías Utilizadas


PHP

MySQL

PWA

Service Worker

JavaScript

Tokens con TTL

Módulos y Endpoints

🏠 Propiedades

api/propiedades.php — cartera de inmuebles en seguimiento.

👤 Propietarios

api/propietarios.php — captación: contactos con el dueño del inmueble.

🧑 Inquilinos

api/inquilinos.php — seguimiento del lado del arrendatario.

🚶 Visitas

api/visitas.php — visitas concertadas y su resultado.

💬 Plantillas

api/plantillas.php — mensajes reutilizables para el contacto habitual.

📈 Estado de seguimiento

api/seguimiento_meta.php — metadatos del pipeline de contacto.

🔐 Sesión

api/login.php y api/logout.php — autenticación por token.

⚙️ Instalación

setup.php — creación del esquema, protegida por clave.

🔄 Migración

api/migrate_v2.php — actualización del esquema sin perder datos.

Arquitectura

Frontend de una sola página en index.html con la lógica repartida en tres ficheros: api.js centraliza las llamadas, captacion.js el flujo de propietarios y seguimiento.js el de contacto. El backend es una API PHP con un endpoint por recurso y _db.php como conexión compartida.

cas/
├── index.html             # aplicación de una página
├── manifest.json          # instalable como app
├── service-worker.js      # caché y soporte offline
├── setup.php              # instalador con SETUP_KEY
├── schema.sql             # 8 tablas
├── js/                     # api, captacion, seguimiento
├── css/
├── assets/                 # iconos PWA
└── api/                    # un endpoint por recurso + _db.php

Base de Datos

8 tablas en schema.sql. La tabla tokens es la que sostiene la sesión: no se usa la sesión de PHP, sino tokens con caducidad configurable.

TablaContenido
usuariosCuentas de acceso de los comerciales
tokensTokens de sesión con su caducidad (TOKEN_TTL, 30 días por defecto)
propiedadesInmuebles en seguimiento
propietariosContactos del lado de la captación
inquilinosContactos del lado del arrendamiento
visitasVisitas concertadas y su resultado
plantillasMensajes reutilizables para el contacto
seguimiento_metaEstado y metadatos del pipeline de seguimiento

Seguridad Implementada

  • Autenticación por token con caducidad configurable mediante TOKEN_TTL, no por sesión de PHP.
  • setup.php protegido por clave de instalación (SETUP_KEY), que debe cambiarse antes de publicar.
  • Credenciales de base de datos fuera del código, en variables de entorno.
  • Conexión centralizada en api/_db.php con sentencias preparadas.
  • Los endpoints validan el token antes de devolver cualquier dato.

Retos Técnicos y Decisiones de Diseño

Tokens en lugar de sesiones de PHP

Una PWA que se usa desde el móvil durante horas y que puede perder conexión encaja mal con la sesión de PHP, que caduca por inactividad del servidor. Un token propio con TTL configurable — 30 días por defecto — permite que el comercial no tenga que volver a entrar cada mañana.

Offline en una herramienta de calle

La aplicación se usa visitando inmuebles, donde la cobertura es irregular. El service worker cachea el esqueleto de la aplicación para que abrirla no dependa de la red, aunque la consulta de datos sí la necesite.

Migrar un esquema ya en uso

api/migrate_v2.php existe porque el esquema cambió cuando ya había datos dentro. Separar el instalador inicial de la migración evita el error clásico de reimportar el schema.sql sobre una base con información y perderla.

Mi Rol

Desarrollador full stack — autor único.

Modelo de datos, API por recurso, autenticación por token, frontend de una página, configuración de la PWA e instalador con clave.

Estado del Proyecto

Aplicación funcional con esquema instalable, migración a la versión 2 y configuración por variables de entorno. Desarrollada para el seguimiento comercial de una inmobiliaria real.

Código y Enlaces

La configuración (credenciales de base de datos, SETUP_KEY y TOKEN_TTL) se define por variables de entorno y no se sube al repositorio.