PropTech platform built on 20+ interviews
Two audiences, one data model, and no existing designs on either side.
Designed both the government and consumer product sides as the sole designer.
Before opening Figma, I spent weeks calling Pennsylvania county offices. What data did they have? What format? Where did the process break down? Everything that followed came from those calls: the IA, the upload system, how the consumer side surfaced property data.
Keytrn is a dual-sided platform: a data entry portal for county governments and a property browser for everyday homebuyers. The final product flows are on the homepage. This page covers the research and decisions behind them.
The problem
The platform had to solve for two audiences with completely different needs, workflows, and mental models, all with the same underlying data. Government users needed structured data entry tools; consumers needed a browsable, Zillow-like experience. Neither side had been designed. Both had to work together.
The work
Started with primary research: directly calling Pennsylvania county offices to understand judicial, upset, and repository sale workflows, how properties are processed, what data formats look like in practice, and where manual processes break down. Used NotebookLM to organize call notes by county, then used its AI to summarize patterns and surface inconsistencies across municipalities. These findings informed every design decision: card structure, data hierarchy, input modals, and error handling. Worked as the sole designer across both product sides simultaneously.
Research
A Butler County call summarized and transcribed in NotebookLM, with a direct question pulled from the transcript to surface a specific answer. This was the workflow across 20+ county offices: calls organized by municipality, then queried to find patterns and inconsistencies across jurisdictions. I also ran a moderated interview with a homebuyer who had gone through the foreclosure process firsthand: every pain point, every friction, in detail. Then a tax property conference in Savannah. The platforms dominating this space: paywalled, $100+/month, built exclusively for real estate investors. Regular homebuyers had nothing.
The data already existed. Counties had it on office lists sold at varying prices, in PDFs on their websites, or in tables they maintained themselves. No central place. No standardization. No way for a regular buyer to access any of it. The portal let counties upload whatever they already had (CSV, PDF, or manual entry) without changing how they worked. And it gave them something back: a dashboard to see their own inventory, track what was selling, and identify areas with the most blight. That changed the pitch from "give us your data" to "here's a tool that works for you too."
Information Architecture
Government portal IA mapped in Miro. Built around how county workers actually file records across judicial, upset, repository, and sheriff sale types, not how we wished they would.
System Architecture
Full 4-layer architecture built in Figma. Both products share the same data model, but the government and consumer sides serve completely different users. Mapping it at this scale forced real decisions: what data counties could provide, what APIs would fill the gaps, and what had to wait.
Key design decisions
Build a portal, not just buy the lists
The original plan was to purchase county foreclosure lists and pipe them into a consumer app. But lists go stale fast, vary in quality county to county, and buying them one by one doesn't scale past Pennsylvania.
Build a government upload portal so counties can submit and manage their own data directly, supporting CSV, PDF, manual entry, and batch uploads.
Fresh data, flexible uploads, and a system that works across states without a county-by-county operation. Counties got something in return: a dashboard to track their own inventory and monitor neighborhood health. That changed the pitch from "give us your data" to "here's a tool that helps you too."
Design for chaos, not perfect data
Calling 20+ Pennsylvania counties revealed that foreclosure data is inconsistent across the board. Different sale types, different workflows, different formats. County workers had 5 to 10 minutes and no patience for a complicated tool.
Structure the government portal around three areas: Search, Upload, and Management. Left-side navigation to switch between them. Tabs within sections to preserve context between tasks.
Normalizing the data was a long-term infrastructure problem. The design addressed it immediately: flexible enough to accept messy input, simple enough that a county worker could upload a batch and leave without training.
Explain the sale type, don't just label it
Judicial, upset, repository, and sheriff sales mean different things legally and financially. Most homebuyers have no reason to know the difference. Getting it wrong can cost them.
Show sale type as a badge on every listing card. On the detail screen, include a plain-language explanation of what that sale type means and what the buyer is getting into.
The platform's purpose was to give regular people access to data that investors have always had. Understandable data is the whole point. Showing the label without context recreates the same problem in a different interface.
Choose trust over growth: blue wins the AB test
The platform serves government workers and first-time homebuyers at the same time. It needed to feel credible and approachable to both.
Ran AB testing with 30 users across three color options. Dark forest green and navy blue came out nearly tied. Chose blue.
Green signals growth and community. Blue signals trust and professionalism. For a platform handling financial and legal property data, trust mattered more. Airbnb-level simplicity applied to a platform that could easily read like a government form.
Resolve the business structure before going further
A non-profit structure made sense for the government portal (counties won't work with a company they think is profiting from their data), but the consumer app needed a for-profit model to sustain itself. You can't run both under one entity. Co-founders couldn't align on ownership or structure.
Applied to the UGA Business Law Clinic, a program where law students work on real cases under a practicing attorney, and brought the full problem to them: entity type, IP ownership, and equity agreements.
Rather than let the stalemate block progress, I brought in outside counsel. The recommendation: form an LLC, establish early-stage IP protections, and put equity in writing from the start with a plan to distribute once roles were formalized.
UGA Business Law Clinic
I applied to the UGA Business Law Clinic after the co-founders couldn't agree on entity structure. The conflict was straightforward: a non-profit made sense for the government portal (counties won't work with a company profiting from their data), but the consumer app needed a for-profit model to sustain itself. You can't run both under one entity. I brought the full problem to the clinic: entity type, IP ownership, equity structure. Their recommendation: form an LLC, establish early-stage IP protections, and put equity in writing with a plan to distribute once the team formalized roles. That gave the project a legal foundation it didn't have before.
Reflection
One gap in the county calls: I never asked how many people per office manage foreclosure records. That answer would have directly shaped the permissions model. I'd ask it first. The hardest part of this product was never the design. It was county adoption. Government sales cycles are slow, and every county operates independently with no central authority to pitch. The pilot strategy: 3-4 counties, small enough to move fast, enough to prove the model before expanding to other states. The next design priority is the consumer property detail: a progressive disclosure system that surfaces what each county can actually provide, not a fixed template that breaks when data is missing.