Cassi — designing for the way property managers think about time and tasks

Role

UX design and product strategy

Timeline

October 2025 to June 2026

Team

Visual designer, fractional CPO, UX and product strategist

Outcome

Calendar-first prototype, well received by pilot customers

The problem

Cassi set out to be an AI-powered property management platform. The aim was to help property managers and their field technicians stay on top of maintenance across every property they look after.

We started with two ideas: a product for homeowners and a product for property managers. When the founders chose not to pursue the homeowner direction, we focused on property managers and the field techs they coordinate.

We began the traditional way, with wireframes in Figma. The product kept growing. It wasn't getting clearer.

What we found

We interviewed property managers and field technicians, and we put the prototype in front of pilot customers early. The pattern was consistent. Every feature we were asked to add made potential customers more confused, not more impressed.

We pushed back, but the feature list kept growing. Months in, the founder had us scrap the work and start over.

The lesson was clear: simplicity was the product.

What we changed

A calendar, not a dashboard

Our early designs centered on a dashboard that tried to surface everything at once. But property managers and field techs don't think in dashboards. Their work revolves around time: what's due, who is going where, and what is overdue. So we rebuilt the property manager product around a calendar.

Building at the founder's pace

The founder began vibe coding his ideas over the weekends. That energy was valuable, but it moved faster than static Figma files could keep up with. Our job became turning fast ideas into good experiences, so we changed how we worked.

We built a design system in Figma and used Claude Code to build working prototypes at the founder's pace. That let us apply UX judgment directly to what he was imagining, instead of handing over mockups that were already out of date.

Two users, two products

Property managers and field techs aren't two viewports of one product. They are two different people with different jobs. So we built two products: a desktop experience for property managers, and a mobile experience for field techs.

What happened

Pilot customers responded well to the calendar-based prototype throughout. We rolled off the project in June 2026, when Cassi was ready to bring design in-house. The company has since changed direction again.

What we learned

1. Flexibility in process matters more than loyalty to it. We began with traditional wireframes and ended up building in code. The method had to follow the pace of the product.
2. Simplicity is a strategy, not just an aesthetic. The more we added, the less customers understood.
3. Founder vision and user evidence need to meet in the middle. Fast, instinct-led building is valuable. It works best when someone in the room is protecting the user's point of view.