Cassi Home
Turning an AI vision into a useful homeowner beta
Founding Designer / Product Design Lead
As Cassi’s founding Product Design Lead, I helped a small team turn a broad AI home-management vision into a working Apple TestFlight beta. I led research, product definition, service design, and interface design from a blank slate, focusing the first release on information homeowners could contribute, understand, correct, and use.
Over six months, we brought the experience to 88 beta participants. The product, research, and demonstrations later supported the CEO’s fundraising, which secured an additional $2M in August 2025.
Results at a Glance
The Challenge: Make a Broad AI Ambition Specific Enough to Build
Cassi began with $500K in initial investment and a vision to make intelligent home management accessible to more homeowners. The founding team brought housing-market expertise, backend engineering, and AI engineering. There was no existing product experience, research, brand, prototype, or codebase.
The challenge was deciding what deserved to exist first. An assistant could potentially help with everything from maintenance to household bills, but the team needed a focused release that could earn trust and generate learning within a limited development window.
I framed the initial product around three connected jobs: build a useful record of the home, make that information easy to retrieve and correct, and turn it into relevant guidance.
My Role: Connecting Product Direction, Service, and Interface Design
I owned design across the homeowner experience and directed an external studio’s work on the initial website. I worked directly with the CEO, backend and AI engineers, and investor advisors; a product manager and frontend engineering lead joined as the project progressed.
My role was to establish a shared direction, make tradeoffs visible, and translate a broad ambition into an experience the team could build and test. With no additional design hire, that meant moving between research, product decisions, interaction patterns, and the operational details of onboarding.
Homeowners Needed Help Knowing What to Do Next
I interviewed six homeowners in our intended Long Island launch area, recruited through the founding team’s local network. We qualified participants against ownership, household, income, and lifestyle characteristics. The interviews established directional hypotheses for the beta.
Three motivations kept recurring: protecting family safety, avoiding unnecessary expense, and reducing the time and attention required to care for a home. Homeowners described spending hours finding appropriate maintenance schedules and struggling to identify whom to call when something went wrong.
One participant described an electrical hazard concealed after a bathroom renovation, discovered when a family member returned home and smelled smoke. That story made the emotional weight of uncertainty tangible. It reinforced the need for understandable next steps without implying that an assistant could detect hidden hazards.
I Narrowed the First Release to Protect Time for Learning
The team could imagine investment optimization, automated bill payment, and a broad service marketplace. I kept bringing scope discussions back to the needs surfaced in research and the time required to test a working product.
I helped defer investment optimization and email-linked bill payment. Both introduced complexity and trust requirements before we had established the core value of the experience. Focusing the release protected time for two months of beta learning within my engagement.
Every Contribution Needed to Return Something Useful
An intelligent home assistant depends on detailed information. Asking homeowners to document everything upfront risked recreating the burden we wanted to remove.
I designed onboarding around a simple exchange: each contribution should produce a visible benefit. A document could become a readable summary, an opportunity to correct the record, and something the homeowner could reliably find again.
Progressive disclosure let us collect information in manageable steps while connecting each request to its purpose. The home record could become more useful over time without requiring a complete profile before the first moment of value.
Flexible Responses. Deliberate Boundaries.
Cassi needed to respond to many homeowner questions without forcing every answer into the same format. Working with the backend and AI leads, I developed documented UI primitives covering form, color, spacing, typography, and hierarchy.
I designed stable interfaces for onboarding, navigation, and chat, alongside reusable task cards, appliance cards, data lists, and scheduling controls. Model-composed interfaces were concentrated within conversational responses.
The division gave engineering and AI development a shared visual vocabulary while preserving recognizable interaction patterns around navigation and consequential decisions. The system documented how responses should be composed.
Repeated Uploads Revealed a Confidence Problem
Early beta testing showed that some homeowners submitted the same document more than once because they could not tell whether Cassi had saved it. The repeated action exposed a gap in the feedback: uploading a file did not leave them with a clear way to verify the result.
I designed separate feedback for processing and successful storage, named the document in the confirmation, and connected that confirmation to the Document Hub. Homeowners would have a persistent place to find the file instead of relying on the conversation alone.
The design also separated saving the source from verifying its interpretation. A stored policy could still contain incorrectly extracted details, so review and correction remained explicit steps.
The beta observation informed a concrete interface change. The follow-up question was whether homeowners could recognize that the document was saved, retrieve it independently, and continue without submitting it again.
Useful Guidance Needs Visible Limits.
Some participants began relying on Cassi for consequential decisions within their first week. That made inspectability and correction especially important. Response instructions and supporting systems were designed to distinguish assumptions from established information and connect answers to sources where available.
The beta could provide guidance and links for homeowners to act on. Broader integrations for booking technicians and arranging deliveries remained a next-stage ambition.
The Home Visit Was Part of the Product
I proposed assisted intake to help establish a useful home profile while introducing homeowners to Cassi. During the first visit, I observed the experience alongside the CEO and engineers and identified moments where the service and application needed to work together.
The CEO subsequently onboarded the beta cohort through a dedicated administrator interface. Testing revealed that visits could emphasize the company vision more than consistent home documentation.
That learning informed a recommendation for a more structured service delivered by specialists with home-inspection experience. I also advocated exploring subscription pricing that spread onboarding costs over time. The specialist model and its economics remained proposals to validate.
Using the Beta as an Ongoing Design Input
We recruited 88 beta participants through the website, selecting for characteristics aligned with our initial audience. During the final two months of my engagement, in-app feedback connected participants directly with the founding team, and remote viewing supported usability sessions inside the application.
I reviewed feedback and analytics daily and used the findings to inform weekly updates. The learning extended beyond usability: requests to involve spouses and other household members exposed a distinction between the person using Cassi and the home record they shared.
That informed a household account structure designed for a later release. One home could support multiple household members without treating each person as a separate home.
The Beta Exposed the Next Product Boundaries
I designed and documented two extensions: household access around a shared home record, and a contextual assistant that could suggest useful next steps during an active session.
The contextual surface addressed a different question from processing feedback: “Is there something I should act on?” It offered a direct route into the relevant information or action without waiting for another prompt.
Both concepts were prepared for future release.
Measure Useful Support Beyond App Opens
Engineering analytics recorded an average of 54 daily active users and 88 weekly active users across the two-month beta. Active use meant a unique person initiated a prompt session or accessed home-system information.
Those figures showed recurring interaction within the recruited cohort, but they did not fully describe the value of a home-management assistant. Useful notifications could help homeowners without requiring an app visit. I challenged the assumption that more daily opens should be our primary objective.
I advocated a subscription direction aligned with ongoing household benefit and proposed exploring a monthly summary of demonstrated savings. A broader measurement framework would need validated benefit and cost measures beyond engagement.
Next Stages to Validate
Whether homeowners complete useful maintenance actions with less effort.
Whether extracted information is accurate and successfully corrected when needed.
Whether assisted onboarding produces a useful home record at a sustainable cost.
Whether multiple household members can use the record with appropriate permissions.
