Role
Founding Product Designer
Collaboration
CEO,
CTO
1 Engineer
Duration
August 2023 - December 2024
Disclosure
4,500+ properties
UI shown: Final redesign completed pre-sunset. Earlier version remains live at zonesage.co
/Market Gap
What if short-term rental operators had a financial tool actually built for them?
Short-term rental operators have real tax advantages available to them, but only if their finances are precise. Most were stuck doing manual data entry or handing their accountant a pile of bank statements and hoping for the best. Existing tools were too generic for STR finances or too complex for a solo operator. Nobody had built something specifically for this person.
/Solution
ZoneSage: A transaction tracking platform purpose-built for short-term rental operators
ZoneSage ingests transactions from property management systems, bank statements, and historical CSV imports, automatically categorized in the All Transactions view, flagged for operator review in Needs Review, and compiled into a tax-ready P&L report for your accountant.
Property-level dashboard for tracking performance across every unit.
Review the transactions the system wasn't sure about, one at a time or in bulk.
Pull reports to understand your finances and share clean numbers with your accountant.
/User Needs Research Findings
Operators were stuck between tools that were too complex and processes that were too manual.
I interviewed 40+ operators through cold calls and direct messages to understand how they were actually managing their finances. Three problems came up consistently enough to shape everything we built.
The core problems of what exist and need to be addressed
Problem 01
Operators were typing months of transactions in by hand.
What the product had to do
The transactions had to come in on their own.
Problem 02
Existing tools took longer to set up than doing the books manually.
What the product had to do
Property-level setup had to be quick and easy.
Problem 03
Operators were paying accountants to categorize transactions.
What the product had to do
The categorizing had to happen before the accountant saw it.
/Domain research
STR finances don't work like generic accounting
Fulfilling what operators needed required understanding a domain most tools get wrong. Every transaction has to be attributed to a specific property, tagged to the right tax category, and treated differently depending on its source.
I worked with 5 accountants and CTO to map the most common transaction rules before designing anything. That work became the interpretation layer the entire product was built on.
Example transactions rules
/Design Approach
Designing Around a Four-Stage Flow
Once we understood the domain, the product structure became clear. Every operator interaction maps to one of four stages: connect your properties, ingest transactions from every source, categorize and attribute automatically, and surface results operators can trust.
The complexity lives in the third stage. How the system interprets and attributes data determines what operators see and whether they trust it. That's where the design decisions mattered most."
Connect your property portfolio
Ingest transactions from every source
Categorize and attribute automatically
Surface results operators can trust
/Key design decision
Where trust actually formed
The system couldn't be certain about every transaction. Rather than hiding that uncertainty behind silent automation, we made it visible. Operators could see exactly how each transaction was interpreted, why the system wasn't confident, and confirm the outcome.
Every confirmation taught the system. A vendor mapped once would be recognized automatically the next time, attributed to the right property, assigned the right category. The more operators engaged, the less manual work remained.
Transaction detail panel design choice
Transaction detail side panel opens by default with a flagged transaction loaded, so review is the first action, not an extra click. The "why it was flagged" context sits right where the decision gets made.
Bulk transaction design choice
Bulk mapping mostly helps solo operators clearing a backlog; LLC operators have cleaner books and rarely need it. So it stays hidden until toggled, keeping the detail panel the default focus.
/Iterations
Dashboard redesign
Operators at different scales wanted different things from the same screen. Rather than pick a default, I made the dashboard configurable. Operators choose which metrics to surface and in what order.
The card grid takes after Stripe's approach to financial dashboards. Every metric card sits on the same grid and holds the same shape, so cards can be reordered, added, or removed without the layout breaking.
/Reflection