Real Estate Ledger
Project Summary
Real Estate Ledger is a property and document management product for homeowners, builders, real estate investors, and property teams. I was brought in as the product designer, but the useful version of the role was never just making screens. The product needed a clearer interface, a better signup path, a marketing site, a design system, analytics that could answer real business questions, and documentation that did not drift away from the product every sprint.
So the work turned into a pretty wide product systems role. I designed in Figma, built a separate design/prototype repo from scratch, shipped code into the production app, joined every sprint planning and demo, and wrote the docs and specs that helped the team make decisions. In my mind, that is the kind of design work that actually matters: not just what the page looks like, but whether the team can understand it, build it, measure it, and keep improving it.
The Design Sandbox
One of the most important things I built was not a single feature. It was a separate design environment for the product. The main app had real production constraints, so I created real-estate-ledger-design as a clean prototyping repo where I could quickly explore dashboards, billing states, property health, onboarding, reports, and document workflows without waiting for every backend decision to be settled.
That repo ended up with roughly 100 commits and became a place to make ideas concrete. For the dashboard redesign, I added dev-only routes, mock data, spec sheets, and full app-shell previews so the team could look at a real interface instead of trying to imagine a Figma frame becoming a product. It helped move conversations from “do we like this?” to “does this actually help a homeowner or builder know what to do next?”
Product Design Work
The product surface was broad: dashboard, onboarding, property pages, documents, asset management, vendors, reports, billing, notifications, settings, and the marketing site. A lot of the work was about reducing ambiguity. The dashboard, for example, should not open with vanity stats. It should answer the question a homeowner actually has: what needs attention?
That led to the property health model, document review cards, vendor favorites, upcoming work, portfolio overview for builders, and more task-oriented dashboard sections. The same thinking showed up in the report builder, where I pushed for a template-first flow: pick the kind of report first, then the property. It is a small IA decision, but it changes the user's mental model from “where do I start?” to “what am I trying to make?”
Analytics System
The most technically significant thing I built was the full-funnel analytics system. REL had a marketing site on one domain and the app on another, which meant a user could visit pricing, sign up, pay, and start using the product while the analytics treated that journey like disconnected fragments. That is not really analytics. It is just pageviews wearing a nicer outfit.
I built a three-layer system: a typed tracking plan, a provider-agnostic analytics core, and plugins for GA4 and Meta Pixel. The signup funnel tracked the path from pricing CTA to account creation, plan selection, checkout, signup, and product activation. The same system handled cross-domain identity, user identification after authentication, separate dev/staging tracking, Meta standard-event mapping, and product events like property creation, document review, asset creation, and report generation.
The goal was not “add GA.” It was to give the team a way to stop guessing. If Meta is optimizing ads, it should optimize against real conversion signals. If product is changing onboarding, the team should be able to see where people drop. If someone becomes a paid user, the anonymous marketing journey should connect to that account instead of disappearing.
Docs That Keep Up
I also built the help center documentation system. This was not a one-time content pass. I set up a Featurebase help center and a GitHub Actions pipeline that uses an AI writer/reviewer loop to generate or update documentation when production changes ship. The writer researches the code changes, drafts the article, then the reviewer scores it and sends it back if it is not good enough.
That is the kind of automation I care about: not novelty for its own sake, but a system that removes a real recurring problem. Product docs usually rot because nobody owns the tiny update after every change. The pipeline makes that maintenance part of the shipping process.
What I Like About This Work
REL is probably the clearest example of how I work when the problem is big enough. Design, analytics, marketing, frontend, and documentation all affected each other. A pricing CTA affects attribution. A billing downgrade flow affects property access. A dashboard card affects whether the user understands the product. A help article affects whether support has to explain the same thing again.
I like working in that middle space. It is a little messy, but it is where the important decisions usually live.
