Frontend
- Next.js 14 (App Router), React 18, TypeScript, Tailwind CSS.
- Componentes de servidor y cliente; búsqueda y filtros.
Buscador de propiedades en la Región Metropolitana de Chile![]()
Este es un proyecto de portafolio para mostrar cómo funciona un agregador/buscador de propiedades real en la Región Metropolitana de Chile![]()
La idea es que puedas navegar, filtrar y buscar datos actualizados sin las complicaciones de un sitio comercial
Aviso: No soy corredor de propiedades ni acepto pagos; esto es una vitrina técnica
Para que esto funcione, armé el recorrido completo: desde el frontend y el backend, hasta la base de datos. El motor principal son pipelines en Python que automatizan la recolección de datos desde fuentes públicas y los dejan listos para que tú los explores en el catálogo.
De la recolección a la pantalla, en cuatro pasos. Sin jerga innecesaria.
Recolección Automatizada
Los avisos se obtienen de fuentes públicas mediante automatización programada (procesos que se ejecutan sin intervención manual en cada aviso). Así se mantiene un flujo ordenado y repetible.
Procesamiento Automatizado
Los datos se limpian, ordenan y validan para que puedas comparar precios, comunas y tipos de operación de forma coherente. Lo que no cumple reglas básicas no llega al catálogo que ves aquí.
Almacenamiento Automatizado o Manual
La información consolidada vive en una base de datos en la nube (PostgreSQL vía Supabase). Esta web no escribe en esa base desde el navegador: solo lee y muestra lo ya cargado/almacenado en la base de datos mediante los procesos de ingesta automatizados o de manera manual.
Presentación
Aquí tienes búsqueda, filtros y favoritos (los favoritos se guardan en tu propio navegador). Quien administra el proyecto puede usar un panel privado para ver métricas y el historial de actualizaciones cuando el entorno está configurado.
Aquí tienes el stack ordenado por capas — Python, SQL/Postgres, React/Next, TypeScript, backend y automatización, además de despliegue. Abajo está el desglose con nombres concretos por capa.
El sitio público solo lee el catálogo; la recolección y el trabajo pesado ocurren fuera del navegador.
Las capas 1 a 4 son el camino de una petición cuando navegas. La capa 5 corre aparte y escribe en la base; el navegador no habla con ella directamente.
1 · Navegador
Aquí interactúas con el catálogo: búsqueda, filtros y favoritos guardados solo en tu dispositivo.
2 · Presentación (frontend)
Next.js / React: dibuja la interfaz y pide datos al servidor de solo lectura.
3 · Aplicación (backend)
API en Next.js: lógica y credenciales en el servidor; nada de secretos en el cliente.
4 · Datos persistentes
PostgreSQL (Supabase): catálogo, políticas de acceso y lo que la vitrina puede leer.
5 · Automatización
Pipelines e ingesta (Python, jobs, scripts): actualizan la base por fuera del sitio público; no “sirven” la página.
/api).docs/.Cuando una publicación tiene su precio en UF, el sitio muestra la conversión aproximada a CLP para que puedas comparar valores sin salir de la página. Esto es complementario al proyecto principal y funciona de la siguiente manera:
¿De dónde sale el valor de la UF?
El sitio consulta la API pública de mindicador.cl/api/uf, que publica el valor oficial del Banco Central de Chile. La UF se actualiza diariamente.
¿Cómo y cuándo se actualiza?
El comportamiento se resume en tres puntos:
localStorage) para que persista entre recargas de página sin necesidad de re-consultar la API. Si la API no responde, se usa el último valor guardado.¿Y en las páginas informativas?
En páginas como esta o Términos y Condiciones el aviso de uso no aplica, por lo tanto la UF no se carga en esas rutas. El valor solo se utiliza activamente en las páginas de búsqueda y resultados.
Este proyecto tiene limitaciones intencionales:
Para consultas sobre el proyecto:
contacto@estacioninmobiliaria.cl