A two-sided PA tax sale platform with AI for counties and homebuyers
Homebuyers had nothing. Counties had no way to reach them. Both sides needed a product that didn't exist.
- ○ Designed and built both sides of the platform solo in 5 months.
- ○ Live data pipeline with geocoding, Street View, and sale type classification.
- ○ Research across 20+ county offices produced the outreach playbook for the first pilot.
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 two-sided PA tax sale platform: an upload portal for counties and a property browser for homebuyers. The final product flows are on the homepage. This page covers the research and decisions behind them.
For access, email robjonesdesigns@gmail.com.
The problem
Pennsylvania tax sale properties are buried across 67 county websites, courthouse PDFs, and spreadsheet notices. No consumer product exists for first-time homebuyers. The only tools in the market cost $100+ per month and are built for professional investors. Counties manage their inventory in isolation with no shared infrastructure and no way to reach buyers at scale. The platform had to solve for both sides: give counties a modern portal, and give homebuyers a way to understand what they are actually buying.
The work
Started with primary research: calling Pennsylvania county offices to understand tax sale workflows. The questions:
- ○ What data counties have, and in what format
- ○ How properties move through upset, judicial, and repository stages
- ○ Where manual processes break down
Used NotebookLM to organize call notes by county, then queried it to surface patterns and inconsistencies across municipalities. These answers shaped every design decision.
Designed both product sides simultaneously, then built the consumer app myself. React front end, Supabase backend, a data pipeline pulling live listings from public records, geocoding and Street View on every property, weighted scoring to classify sale types from legal language, and an AI assistant on Claude Haiku that answers questions on every page.
Calling counties: County quotes in NotebookLM
Greene County call, transcribed and queried in NotebookLM. I also ran a moderated interview with a homebuyer who went through the foreclosure process firsthand, and attended a tax property conference in Savannah. Three different angles on the same problem.
What's the process for maintaining and updating these lists? Is it similar to other counties in the state, or do you do it a unique way?
“I have no idea if people do them different. I'm not sure if the other ones do them different. That's the way we do them, just 30 days prior to the sale.”
Is that process pretty standard across all counties, or does your office do things differently?
“I don't know. I can only tell you, for Butler County, we take care of Butler County. I don't know how other counties do theirs.”
The Q&A quotes above were the tell: every county knew their own process but had no idea about anyone else's. Getting the data was wildly different per county. Some sold hard copies at the office. Some buried PDFs on their website. Some required a parcel number cross-referenced on a separate assessment site to get anything usable. I tried to pull lists from several counties. It was a ton of work. No standard for any of it.
Design for chaos.
Make the portal accept whatever counties already have. PDF, photo, screenshot, CSV, manual entry. Whatever is on their computer or desk goes in without reformatting. Let the tool do the work.
Clerks have 5 minutes. Then they move on. If Keytrn asks them to reformat their data, they walk away. The tool has to meet them where they are. OCR handles the images, Claude extracts and normalizes the fields, the clerk confirms and moves on.
Every county operates as if it's the only one. 67 counties, 67 workflows. The lesson from the calls: the product has to flex around every county's process, not the other way around.
Designing the portal: Portal IA in Miro
Government portal IA mapped in Miro, grounded in how county workers actually file tax sale records, not how we wished they would. Upload, Manage, and Report as the three primary zones. Tabs within each to preserve context between tasks.
Early on, the obvious approach was to chase county lists: buy what we could, scrape the rest. But the data is messy, listings go stale, quality varies by county, and you pay forever to maintain the chase.
Build the portal. Don't chase the lists.
Build a portal counties own, not a data pipe. Upload, manage, report, and a dashboard showing their inventory, sales trends, and where blight concentrates. A tool that works for them, not just from them.
Counties know their inventory. They just don't have a view of it. Give them the view. Years building enterprise dashboards made the shape of it obvious. That flips the pitch from "give us your data" to "here's a tool that helps you too." Fresh data stops being an extraction problem. It becomes a partnership.
Testing the pipeline: 4-layer architecture in Figma
Full 4-layer architecture in Figma. Both sides share one data model but serve completely different users. Mapping at this scale forced real decisions about data sources, API gaps, and what to defer.
I started with a question, not a strategy. Could I pull live public records and enrich them? Geocoding, Street View, sale type classification. Could I actually pull this all together?
Prototype the pipeline with public data.
Pennsylvania publishes tax sale legal notices as public records required by state statute. Pull the notices, layer the enrichment: weighted scoring to classify sale types from legal language, geocoding for map pins, Google Street View per listing, field normalization across county formats.
This was never the long-term strategy. It was the experiment. If I could prove the pipeline worked on chaotic public data, counties would eventually feed it cleaner data through the portal. The pitch becomes: "we already have your listings, here's what we enriched on top. Upload to make it better." The prototype turned into a demo.
Building consumer-first
Government sales cycles are slow. No county is going to adopt a portal from a slide deck. They need something they can click through and evaluate. And consumer apps in the space all looked alike, copying each other, with investor tools hidden behind $99-$699/month paywalls.
Build what people see.
I designed a consumer app prototype first, something counties could test and see. The feel of Zillow or Redfin, carrying the data investors pay for, made digestible for homebuyers.
If municipalities can touch a working prototype of their data treated well, the pitch changes. They see a view of their inventory they don't have today. The prototype becomes the demo: something they can click, not just a slide deck. That's what closes a government sales cycle.
Designing for homebuyers: Detail view with sale type signals
Every foreclosure platform in this market is built for professional investors. Keytrn is the first built for first-time homebuyers, with plain-language context on every listing.
Homebuyers going into tax sales are flying blind. They can call the county, Google the process, stitch together fragments. Most don't. They show up to an auction and lose money on risks they didn't see coming.
Make the risk obvious.
Surface the risk on the listing itself. Sale type badges use color: green for liens cleared, amber for liens survive. Price tooltips explain what the number actually means. The "Before you bid" checklist changes per sale type. The Learn section covers the fundamentals. Homebuyers don't leave the product to understand what they're walking into.
This came out of Honeywell. Industrial dashboards use color to signal criticality because decisions can't wait. Green, amber, red, information surfaced at a glance. The same principle works here. A $5,000 tax sale can carry a $150,000 mortgage. If the risk isn't visible the first time someone sees the listing, they find out at the auction.
Shipping Ask Key: Consumer and government sides
Left: a buyer on a property detail page asks about liens and risk.
Right: a county clerk asks about the upload workflow.
Same model, same tone.
Both sides had questions. First-time homebuyers didn't understand sale types, liens, or redemption periods, so they clicked away or called the county. Clerks reported spending two hours a day answering the same three buyer questions: is the sale still on, are there liens, and how much do I need to bring. Static educational content didn't solve either side.
Give both sides an expert.
Built Ask Key: an AI assistant on every page. Claude Haiku via serverless API routes, trained on PA tax sale law. On consumer, it knows the property you're looking at. On portal, it knows the upload workflow. Guardrails so it doesn't hallucinate. Name pulled from Keytrn, friendly and on-brand. Gradient CTA so people see it without an annoying popup.
Both sides are people with questions. Give both sides the same tool. Buyers get an expert they couldn't otherwise afford. Clerks get their two hours back, and can cross-reference other counties when they don't know something. The pitch to counties turns into "use our portal and your call volume drops." Guardrails keep it real, not hallucinated.
UGA Business Law Clinic
I didn't know whether this should be a non-profit or a for-profit. The portal felt like a public good. The consumer app needed revenue. I took the whole question to UGA's Business Law Clinic: entity type, IP ownership, equity structure. They said LLC, protect the IP early, get equity on paper. That gave the project a legal foundation it didn't have before.
Reflection
Cold calls surface workflows but not organizational structure. I learned what each county does, not who does it. That meant the permissions model was shaped by assumption instead of interview data. If I were starting over, I'd pair the cold calls with one deep-dive interview per pilot county to map the org chart, not just the process. And I'd get a letter of intent from one county before building the portal, so the first upload came from a partner, not a demo.