Casascope: Diseño y desarrollo de una plataforma inteligente para el análisis inmobiliario

Tomar decisiones informadas en el mercado inmobiliario puede ser un reto: la información suele estar dispersa, es difícil comparar propiedades de manera efectiva y muchas plataformas priorizan la cantidad sobre la calidad de la experiencia de usuario. En este contexto, surgió la idea de casascope, una plataforma web creada para facilitar la visualización, comparación y análisis de propiedades inmobiliarias, combinando filtros avanzados, visualizaciones interactivas y un diseño elegante y funcional.

El objetivo de este post es compartir el proceso técnico detrás de casascope: desde la definición del problema, pasando por la arquitectura y las decisiones tecnológicas, hasta los retos y aprendizajes obtenidos. Puedes ver el código aquí: casascope en GitHub.

¿Por qué crear casascope?

El mercado inmobiliario está saturado de portales que ofrecen grandes listados, pero muy pocos permiten comparar propiedades de manera visual y profunda. Como usuario, quería responder preguntas como:

¿Qué zonas ofrecen mejor relación calidad/precio para mi perfil?
¿Cómo evoluciona el precio por metro cuadrado en diferentes áreas?
¿Puedo filtrar y comparar propiedades según criterios personalizados y ver tendencias?

Las plataformas existentes no cubrían bien estos puntos, así que decidí diseñar una herramienta que pusiera la experiencia de análisis y la visualización de datos en el centro.

Arquitectura técnica: un stack moderno y flexible

¿Qué stack tecnológico elegí y por qué?

La arquitectura de casascope necesitaba ser:

Interactiva: para visualizaciones dinámicas y filtros en tiempo real.
Escalable: para incorporar nuevas fuentes de datos y funcionalidades fácilmente.
Mantenible: usando tecnologías conocidas y bien soportadas.
Flexible: para integrar tanto scraping de datos como futuras APIs.

Tecnologías principales

Frontend:

- JavaScript (con TypeScript en componentes clave): robustez y typing.

- HTML + CSS: diseño responsive y elegante.

- Librerías de visualización:

- D3.js para gráficos personalizados.

- Leaflet para mapas interactivos.

Backend:

- Python: ideal para el procesamiento de datos y scraping.

- Flask: microframework para endpoints API ligeros.

Persistencia:

- SQLite (fase inicial) por simplicidad; migrable a PostgreSQL para producción.

Otros:

- Node.js (para ciertas tareas asíncronas y procesamiento paralelo).

- Docker (para facilitar el despliegue y reproducibilidad).

Esquema general de la arquitectura

graph TD
    A[Scraper Python] -->|Procesa datos| B[Base de datos SQLite]
    B -->|APIs REST| C[Backend Flask]
    C -->|JSON| D[Frontend JS/TS]
    D --> E[Usuario: visualización y filtros]

Loading diagram...

Componentes principales del sistema

1. Scraper y procesamiento de datos (Python)

Para poblar la base de datos con propiedades reales, desarrollé un scraper en Python capaz de:

Navegar portales inmobiliarios públicos (respetando términos de uso).
Extraer información relevante: precio, ubicación, superficie, características, imágenes, etc.
Normalizar y limpiar datos, gestionando inconsistencias frecuentes (por ejemplo, superficies mal formateadas o precios en diferentes monedas).
Enriquecer los datos calculando métricas adicionales como precio por m² o ratio de crecimiento.

Snippet: extracción y normalización de datos

python

1def parse_price(raw_price):
2    # Elimina símbolos y separadores, convierte a float
3    clean = raw_price.replace('€', '').replace(',', '').strip()
4    return float(clean)
5 
6def normalize_listing(listing):
7    return {
8        "title": listing.get("title", "").strip(),
9        "price": parse_price(listing["price"]),
10        "surface": float(listing["surface"].replace("m²", "").strip()),
11        # ... otros campos
12    }

2. Backend API (Flask + SQLite)

El backend expone endpoints REST para:

Listar propiedades filtradas por parámetros: precio, zona, superficie, etc.
Obtener estadísticas agregadas (medias, tendencias históricas).
Servir datos geolocalizados para mapas.

Snippet: endpoint de búsqueda avanzada

python

1@app.route('/api/properties', methods=['GET'])
2def search_properties():
3    min_price = request.args.get('min_price', 0)
4    max_price = request.args.get('max_price', 1e7)
5    # ... otros filtros
6    query = """
7        SELECT * FROM properties
8        WHERE price BETWEEN ? AND ?
9        -- otros filtros dinámicos
10    """
11    # Ejecutar query y devolver resultados como JSON

3. Frontend interactivo (JavaScript/TypeScript)

La interfaz de usuario fue una prioridad: debía ser clara, intuitiva y potente. Algunos elementos clave:

Filtros avanzados: sliders, selectores de zona, checkbox de características.
Visualizaciones interactivas:

- Gráficos de precios históricos y comparativas usando D3.js.

- Mapa con propiedades geolocalizadas y agrupamiento por zonas.

Comparador: permite seleccionar varias propiedades y verlas lado a lado.

Snippet: renderizado reactivo de filtros y mapa

typescript

1function updateMap(filteredProperties: Property[]) {
2    markersLayer.clear();
3    filteredProperties.forEach(prop => {
4        const marker = L.marker([prop.lat, prop.lng])
5            .bindPopup(`<b>${prop.title}</b><br>€${prop.price}`);
6        markersLayer.addLayer(marker);
7    });
8}

Decisiones técnicas clave

Durante el desarrollo, hubo varias decisiones que marcaron el enfoque:

Separación de scraping y visualización: Evité mezclar el scraping con la app web, usando Python para la obtención y preprocesamiento, y sólo sirviendo datos ya limpios al frontend.
Uso de TypeScript en el frontend: Si bien muchos componentes están en JavaScript, incorporar TypeScript en las partes críticas (como el manejo de datos y lógica de visualización) elevó la robustez y mantenibilidad.
Visualizaciones personalizadas vs. librerías estándar: Aposté por D3.js en vez de librerías "plug-and-play" para tener control total sobre los gráficos y animaciones.
Persistencia simple inicialmente: SQLite permitió iterar rápido, aunque tengo claro que para escalar o multiusuario es necesario migrar a una base relacional potente como PostgreSQL.

Retos técnicos y cómo los resolví

1. Normalización y limpieza de datos

Los portales inmobiliarios suelen tener datos inconsistentes: superficies mal escritas, precios en diferentes formatos, ubicaciones ambiguas… Implementé múltiples funciones de parsing y validación, y un sistema de logging para detectar y corregir casos problemáticos.

2. Rendimiento de las consultas filtradas

Con cientos o miles de propiedades, los filtros complejos podían ralentizar la respuesta. Optimizé las queries SQL y añadí índices en los campos de búsqueda más frecuentes (precio, zona, superficie), logrando tiempos de respuesta <300ms incluso con filtros múltiples.

3. Sincronización de datos en frontend

Me encontré con problemas de sincronización entre los filtros activos y las visualizaciones (especialmente cuando hay cambios rápidos). Usar un estado global bien gestionado (con hooks personalizados en JS/TS) y debouncing en los inputs resolvió estos glitches.

4. Mapas y geolocalización

Algunas propiedades carecían de coordenadas precisas. Implementé una llamada a la API de OpenStreetMap Nominatim para obtener la lat/long a partir de direcciones, y añadí un sistema de caché para no saturar la API.

Resultados y métricas

Aunque casascope está en una fase temprana, ya permite:

Visualizar cientos de propiedades de manera fluida.
Comparar propiedades por múltiples criterios con una experiencia rica.
Explorar tendencias de precios y zonas con gráficos y mapas.
Filtrar en tiempo real con latencia mínima.

Impacto inicial:

Durante pruebas internas y con usuarios beta (agentes y compradores particulares), se reportó:

Mejor comprensión del mercado: gracias a la visualización clara de datos y comparativas.
Ahorro de tiempo: en la búsqueda y análisis de propiedades relevantes.
Feedback positivo sobre la interfaz: destacando la usabilidad y el look & feel.

Aprendizajes y mejoras futuras

Lo que aprendí

La importancia de la calidad de datos: sin datos limpios, hasta la mejor visualización pierde utilidad.
Lo útil que es modularizar el scraping y el backend, para iterar rápido y mantener el sistema.
El valor de visualizaciones personalizadas: permiten insights que las tablas tradicionales no muestran.

Próximos pasos

Migrar a PostgreSQL para mejor escalabilidad y manejo de usuarios.
Integrar APIs públicas para enriquecer el dataset (transporte, servicios cercanos…).
Añadir autenticación y favoritos para usuarios registrados.
Optimizar el scraper para detectar cambios en las propiedades y mantener el dataset actualizado.

Conclusión

Desarrollar casascope ha sido una experiencia muy enriquecedora, que combina scraping, backend, data engineering y UX/UI. Si te interesa contribuir o probar la plataforma, te invito a visitar el repo de casascope en GitHub.

¿Tienes dudas técnicas o sugerencias? Me encantará leerte en los comentarios o issues del repo 🚀

Javier Santos Criado

Ingeniero de IA & desarrollador full-stack

Apasionado por crear soluciones prácticas usando tecnología

Cómo Crear un Comparador de Propiedades Inmobiliarias con Python y JavaScript