There’s a question worth asking about most property data companies: does the data come first, or the business problem? On a recent episode of The Innovation Blueprint Podcast — ORIL’s series on emerging PropTech, hosted by ORIL’s CEO Roman Havrylyuk — that question sat at the center of a conversation with Ivo Draginov, co-founder and president of BatchService.
Ivo and his co-founders, Jesse and Annie, started out in 2018 as active real estate investors doing nationwide wholesaling, not as a data company. The data infrastructure came later, built to solve their own operational problems before it became a product other companies could use. That order — business need first, data platform second — turned into a broader conversation about how property data gets built, normalized, and made usable by AI systems today.
Three threads from that conversation are worth pulling out, whether you’re evaluating a data vendor, building on top of property data yourself, or just trying to understand where AI is actually changing how this industry works.
Building the infrastructure before the product existed
The tools Ivo’s team built for themselves became BatchLeads and BatchDialer, software that let real estate investors source and work deals at scale. The API layer underneath those products wasn’t originally meant to be sold — it existed to keep the investor-facing tools running. It wasn’t until 2019–2020 that the team realized other proptech companies needed the same enterprise-grade infrastructure they’d built for themselves, and packaged it into a standalone product: BatchData.
In 2024, BatchService sold BatchLeads and BatchDialer to PropStream, and the company is now fully focused on BatchData. As Ivo put it on the episode, the difference between that path and the more common one matters: “we didn’t want to rely on a single data vendor.” Instead of licensing one feed and reselling it, BatchService compiles from 17 different data sources and builds what Ivo calls an identity graph for every property — combining public assessor and recorder records with consumer demographics and permit data, then layering predictive modeling on top to estimate things like the likelihood a property will sell or refinance in the next six to twelve months.
Roman noted the same distinction from ORIL’s side of the table, having worked with BatchData’s data feeds directly on client projects: “it comes from a business environment and then into the service. Sometimes startups start the other way around — they start with an idea and then shape it into the business.” Starting from an operational need, rather than a data acquisition strategy, tends to produce a different kind of product.
The customers nobody would have predicted
One of the more useful parts of the conversation wasn’t about the data itself, but where it ends up. Ivo described working with Daikin, the world’s largest air conditioning manufacturer — not an obvious property-data customer. Daikin uses property details, square footage, and permit records (including where solar and AC units have already been installed) to model future demand for unit sizing across the country.
Ring, the camera company owned by Amazon, pulls USPS vacancy data to identify vacant properties and target nearby homeowners with marketing. TruGreen uses parcel size and land data — residential and commercial — to identify and reach new landscaping customers nationwide. And on the more expected end, some of the largest mortgage originators in the country layer BatchService’s predictive models on top of their own refinance-likelihood models. Ivo cited one case with the country’s largest originator where that layering produced a four-to-six percentage point lift over their existing model.
The pattern across all of it: raw data is rarely the end product. It becomes valuable once it’s been normalized, modeled, and pointed at a specific decision someone needs to make.
AI didn’t just speed things up — it restructured the org chart
The most concrete part of the conversation was also the most surprising. At its peak in 2022–2024, BatchService (across its full product suite) employed around 260 people and generated $30–36M in annual revenue. After selling two of its four product lines in 2024, the company was down to around 40 people.
By Ivo’s account, that smaller team is now more productive than the 260-person company ever was — a shift he attributes almost entirely to AI adoption across the business. Data acquisition scripts that used to require dedicated engineering time are now written and maintained with AI assistance. QA testing, previously handled by a team of roughly 20 people, is now handled by a much smaller team using AI tools that Ivo says catch more bugs before release than the larger team did. “10x is really an understatement,” he said of the overall impact.
Roman drew a direct parallel to ORIL’s own delivery model: the team size hasn’t changed, but “whatever we delivered three years ago is probably five to ten X now” — a function of the same AI-assisted tooling showing up across engineering, QA, and data operations rather than one flashy feature.
What “AI-ready” actually requires
Ivo was specific about what makes a data platform usable by AI systems, and it comes down to two things most companies underestimate: identity resolution and machine-readable access.
On identity resolution: the same property can show up with three different address formats across three different source systems — a county assessor might spell out “West,” a permit database might abbreviate it “W,” a demographics database might format it differently again. Left unresolved, that’s three separate records for one property, which is a serious problem for a model trying to reason over the data. BatchService normalizes every incoming address against the USPS database as a source of truth and maps it to a single unique identifier before anything else gets built on top. “We do a lot of work on the back end to be able to normalize everything, map everything to a unique identifier,” Draginov said.
On access: BatchService has fully built-out MCP servers, so AI systems and agents can query the API directly using its documentation, without a developer hand-translating every request. Ivo described a growing pattern of data analysts inside larger companies — not just engineers — connecting directly to the API through an MCP client and asking plain-language questions about property criteria, with answers returning in seconds rather than the hours a custom-built filter used to take.
Where the value is actually moving
Ivo made a point that’s easy to miss if you’re only thinking about data acquisition: raw property data is becoming a commodity. Counties and government agencies are getting more efficient at publishing and redistributing their own records, which means access to the raw feed itself is no longer a defensible advantage. “The money is not in the raw data feeds,” he said. “It’s really in the proprietary analytics and predictive data.”
That view — that the analytics matter more than the raw feed — is also behind a broader shift Ivo described in how this kind of data gets sold. Much of the property data industry still runs on opaque, negotiated enterprise contracts. Ivo argued for the opposite: transparent, published pricing and self-serve access, so a data analyst can get set up and start querying without going through a sales cycle. He called the traditional model “mind-boggling” at this point, given how much easier direct API and MCP access has made this kind of setup elsewhere.
Ivo pointed to real-time weather-impact data as one direction this is heading: identifying, at the individual property level, which homes were hit by a specific storm or hailstorm the day it happened, rather than relying on historical weather patterns, so that roofing, solar, and storm-response businesses know which houses to reach out to immediately rather than weeks later. It’s a small example of a bigger pattern — the more interesting property data products aren’t just bigger datasets, they’re datasets tied to a specific, time-sensitive decision someone needs to make.
On evaluating a data vendor
Asked for advice on choosing between data vendors, Ivo’s answer wasn’t about features. “Companies hide behind marketing lingo,” he said — coverage percentages and accuracy claims that don’t always hold up under scrutiny. His suggestion: test the data directly rather than taking a vendor’s numbers at face value, something he noted is far easier now that AI tools can do a first pass of data analysis for you.
He pointed to BatchService’s own experience being tested by Amazon, which evaluated seven other data vendors over roughly a four-month process before choosing BatchService, ultimately for having what Amazon determined was the best geocoding data available. Roman closed the conversation with a similar observation from ORIL’s side, having worked with BatchService’s data on multiple client engagements: “people are often impressed with the breadth and availability of the data set.”
What this means for teams building on top of property data
Most of what made this conversation useful wasn’t specific to one vendor. Identity resolution, AI-ready access, and the shift toward a predictive-analytics layer sitting on top of raw records — these are the same problems ORIL works through with real estate and proptech companies building their own products, regardless of which underlying data provider they use. Normalizing inconsistent records into a single source of truth, building the pipelines and predictive models that turn raw property data into something a client actually acts on, wiring AI or agent access into an existing platform without weeks of custom integration work — that’s engineering work, and it’s the layer where most proptech products either become genuinely useful or stay a thin wrapper around someone else’s feed.
That’s the part of the stack ORIL builds: full-cycle custom software development for PropTech and real estate companies, from data engineering and AI enablement to scaling a platform once the underlying data and models are in place. If your team is wrestling with any of the problems in this episode — messy or inconsistent property data, an AI layer that needs real infrastructure underneath it, a platform that needs to hold up as usage scales — that’s a conversation worth having with a development partner who works in this domain specifically, not a general-purpose dev shop.
This is the kind of conversation The Innovation Blueprint Podcast keeps returning to — not a single vendor’s product roadmap, but the underlying shifts in how data gets sourced, cleaned, and made usable that everyone building in PropTech is navigating right now.
