Rebuilding a YC Real Estate Tech Stack from the Ground Up
These are the highlights from an episode of Tern Stories. You can watch the full conversation with Bobby Grayson on YouTube, Spotify, Apple, or wherever you get your podcasts.
Quantierra didn’t start out with a product problem—it started with a data problem. Specifically: NYC property data is a mess.
If you want to understand what’s going on with a single parcel of land in the city, you need to connect dozens of open datasets—permits, zoning, liens, violations, co-op documents—and do it across thousands of idiosyncratic formats, naming collisions, and broken schemas. It’s not hard in theory. It’s hard in practice. Nobody had done it well.
That’s what Bobby Grayson stepped into in 2019 as the first engineer: a half-working Ruby codebase, millions of messy records, and a mandate to make it usable—fast.
“This is the most atypical job I’ve ever had—and I worked at WeWork.”
This story traces both how he pulled it off back then—through pragmatic infrastructure, structured automation, and sitting shoulder-to-shoulder with users—and how he’d approach the same challenge today, in a world reshaped by AI.
The problem is the same. The solution looks very different.
Laying the Foundation (2019-2020)
The first problem wasn’t product—it was trust. NYC real estate data is spread across dozens of sources, each with its own format, naming conventions, and gaps. Brokers, investors, and developers make million-dollar decisions based on this mess. Quantierra’s promise was simple but ambitious: “We’ll tell you the full story of any parcel in NYC.” But the codebase they had couldn’t do that reliably.
So Bobby started with the foundation. He rebuilt the data pipeline—150+ rake tasks across a fragile ingestion system—into something structured and resilient. Every parcel had to be resolved to a single, reliable entity. He layered on tests, pushed coverage over 70%, and cleaned up performance bottlenecks. If it wasn’t trustworthy, nothing else mattered.
Once the data worked, he turned to usability. By shadowing brokers day after day, he realized dashboards weren’t helping—they were noise. What users actually wanted was signal: “Email me when a lot with these traits hits the market.” So the team reoriented around triggers and alerts, reshaping the product to fit the real workflow instead of the imagined one.
Eventually, the system didn’t need them. It scraped, matched, validated, notified. It did everything the team had once done manually. “We kind of fired ourselves,” Bobby said. Not out of redundancy—but because the work had been absorbed by the system. That’s what good automation looks like.
Reimagining the Stack (2025)
If Bobby rebuilt Quantierra today, he wouldn’t start with a frontend. He’d start with a schema. A clean Postgres model, backed by versioned data and reliable queries. On top of that: a chat interface. Not a prototype, but the real product. Users could ask questions like, “Show me buildings with underused zoning and recent violations,” and the system would respond with exactly the right data—no UI clicks required.
This architecture shrinks what has to be stable. Instead of reliability spread across dozens of screens and flows, there’s a tight contract: data correctness, query performance, and sensible defaults. Everything else—interfaces, formatting, logic at the edges—can be fuzzy, fluid, and disposable. That flexibility is the point. It means you can change things faster, because the core stays understandable.
And most importantly: this isn’t just a better app for humans. It’s an architecture built for AI. The chat interface is just the first consumer—but the real shift is designing APIs for bots, agents, and copilots to use. That’s why something like an MCP server over Postgres is powerful: it lets both humans and machines ask meaningful questions with minimal translation. The system becomes simpler to understand, easier to adapt, and faster to evolve—because most of the code at the edge is throwaway.
In a world where learning is the bottleneck, clarity is leverage. This is what it looks like to build for that world.
What Changes, Really?
Whether you’re wrangling data in 2019 or building AI-native apps in 2025, the challenge is the same: making complexity legible.
Bobby didn’t scale by adding layers—he scaled by stripping things away. First, the system had to be correct. Then, it had to reflect real behavior. And finally, it had to get out of the way.
That arc hasn’t changed. What’s changed is the surface area. Today, you can build smaller systems with smarter defaults. Keep the core tight and comprehensible. Let everything else—the interface, the logic at the edges—be flexible, fast, even disposable.
It’s worth asking: what would you build if you didn’t have to understand everything at once? What if your system was simple enough that people and AI could navigate it?
That’s where velocity comes from. That’s how big changes get made.
You can find Bobby on BlueSky: https://bsky.app/profile/bobbby.online (yes, with 3 Bs)