Property data is messy by default#
Real estate products run on data from many places: city agencies, open data portals, listings, inspections and your own records. Each source has its own formats, identifiers, update schedule and gaps. Addresses are written five different ways, the same building appears under different identifiers, and a dataset that updated daily last month suddenly updates weekly.
The value of a PropTech platform comes from pulling all of that together reliably and presenting it so customers can act on it: a clear view of each property, a way to search across thousands, and an alert the moment something important changes. That's a data engineering problem as much as an application problem, and it's where I focus.
Signs you need a specialist platform build#
- Your product depends on public property data that has no single clean feed.
- Records from different sources don't match up, so the same property looks like several.
- Customers need to know when something changes, such as a new violation, permit or filing, not just what the data says today.
- Search and maps are slow as the dataset grows into hundreds of thousands of records.
- Your team spends time checking data by hand before customers see it.
What I build#
Data ingestion#
Pipelines that pull from open data portals, APIs and, where needed, scraped sources, running in the background on a schedule with retries and monitoring.
Normalisation and matching#
Addresses standardised, identifiers reconciled, and records from different sources attached to the right building or lot, with review queues for uncertain matches rather than silent guesses.
Property search and maps#
Advanced filters across property attributes and records, with map-based exploration through Leaflet GIS, kept fast with proper indexing and caching.
Monitoring and alerts#
Change detection between ingestion runs, with notifications by email or in-app, in real time where it matters, so customers hear about a new violation before it becomes a fine.
Subscription products#
Stripe billing, plans and limits, customer dashboards and reporting, turning the data into a product people pay for.
AI-assisted analysis#
Summaries of long property histories, classification of issues and natural-language questions over the data. See AI integration.
Case study: Violerts#
Violerts is an enterprise PropTech SaaS that consolidates fragmented NYC municipal property data into one compliance intelligence platform. I led the modernization of its React frontend and Laravel backend:
- municipal data coverage grew from 3–4 to 12+ datasets and agencies;
- 60%+ performance improvement in affected frontend workflows;
- processing moved from synchronous requests to Horizon-based background jobs;
- real-time updates with Pusher and map exploration with Leaflet GIS;
- Stripe billing, AWS infrastructure and CI/CD;
- 1,180+ production commits over the engagement.
Daniel Lee of AZARK, the client behind Violerts, described me as a "Great developer to work with, very knowledgeable".
What your customers see#
The engineering exists to produce a simple experience: a property page that shows everything known about a building in one place, with a clear timeline of records and changes; search and maps that answer "which of my properties need attention?" in seconds; alerts that arrive once, promptly, and say exactly what changed; and reports customers can export or share with their own clients. Getting that experience right is what turns public data into a product people pay for, because the data itself is available to everyone.
Built to scale with the data#
Property datasets grow constantly, and new sources are always on the roadmap. The platform is designed so ingestion runs in the background, each source is its own pipeline, heavy queries are indexed and cached, and adding a new dataset doesn't mean rewriting what already works. See database optimization for how I keep large datasets fast.
Data quality you can stand behind#
In compliance and property products, wrong data is worse than missing data, because customers make decisions and spend money on it. Every pipeline validates records against expected formats and volumes, flags anomalies instead of publishing them, keeps a history of changes so mistakes can be traced and corrected, and records where each value came from and when. Customers see fresher, more trustworthy data, and your team spends less time checking it by hand.
Common PropTech data mistakes I help avoid#
- Treating addresses as identifiers, which splits one building into many records.
- Overwriting data on every import, losing the history customers need to see what changed.
- Synchronous processing of large imports, which slows the app and times out.
- One giant import script where a single source failing stops everything.
- Alerts without deduplication, so customers get the same notification repeatedly and start ignoring them.
Because Violerts runs on New York data, the patterns carry over to other cities and markets: every jurisdiction publishes property records differently, but the work of reconciling them is the same.
Related services#
PropTech platforms combine several of my services: web scraping & data extraction, SaaS development, Laravel development and React & Next.js for the customer-facing product.
Working together#
We start with a free 30-minute call about your product and the data sources behind it. I review the sources, their identifiers and update schedules, and send a written plan covering the data model, pipelines and first product release. Builds run as fixed-scope phases, usually followed by a retainer as new sources and features are added.
Building in PropTech? Book a free call and let's look at your data sources.