My work at Proptech Builders
I contributed to building and maintaining the data pipeline supporting the company’s Multiple Listing Service (MLS) and iBuyer development. I owned the Python processing pipeline for 2M+ raw listings, transforming data from multiple portals into standardized, enriched records for valuation and reporting.
My responsibilities
- I implemented text and image processing for cross-portal matching, from property-name normalization to unit-level metadata and image comparisons.
- I consolidated matching listings into a single property record, retaining source links and combining attributes to address missing information such as amenities and floor numbers.
- I monitored data quality, prepared valuation inputs, and automated explainable valuation reports for brokers and internal teams.
Core tools: Python · PostgreSQL · Amazon S3 · CLIP

Technical approach
I structured the matching process into development-level and unit-level stages. This allowed me to narrow the candidate listings through text and location checks before performing image comparisons.
- Development matching. I used NLP-based name normalization adapted to Thai naming variations, fuzzy matching, and coordinate checks to identify listings within the same development.
- Unit matching. Within each development, I compared floor number, room size, bedroom and bathroom counts, and price to identify listings that could refer to the same unit.
- Image categorization and matching. I used CLIP to distinguish room photographs from images of shared facilities, such as pools, lobbies, and gyms. I then compared room images using CLIP similarity alongside text and unit metadata.
Tracking price changes over time
The existing process added listings as new rows without maintaining an explicit history of each condominium unit’s asking price. I identified the need to track price changes, drawing on temporal data modeling from my Advanced Topics in Database Systems course at KMITL.
Source listings also contained minor changes to facilities, coordinates, and other metadata. I worked with the team to prioritize price history over versioning every attribute. We also encountered missing digits and inconsistent currencies, which required distinguishing data-entry errors from genuine price adjustments.
I decided to keep the latest valid price in the main price field and store previous prices in a JSON array with valid-from and valid-to timestamps. This preserved price history without duplicating the full property record for each change. As the dataset grew, I aimed to balance the need for historical analysis with storage and maintenance requirements, focusing the retained history on price changes.
Processing and storage
I used Python for the main processing pipeline, PostgreSQL as the primary database, and Amazon S3 for images and other artifacts.
Some portals’ image URLs expired quickly. I stored copies in S3 to retain access for subsequent processing. I considered its flexible capacity and pay-as-you-go pricing when addressing the pipeline’s changing storage requirements.
Validation and results
The pipeline eliminated 87% of identified duplicate listings and produced enriched records for valuation and reporting. I conducted manual reviews to check for false matches.