AI-native real estate operations platform

Every product needs a foundation before it can scale.

When I joined Accolade, most of my work was focused on the leasing journey. But as the platform evolved, another challenge became just as important.

Before AI could assign tasks or leasing teams could manage prospects, organizations first needed a way to manage people. Who could access the product? What should they see? Which communities were they responsible for? How should teams be organized?

Over the next several months, I worked with Product Managers and engineers to design the shared platform experiences that answered those questions. Together, these became the foundation that every module relied on.

Adding a user wasn't as simple as sending an invitation.

Each user needed the right role, communities, skills, and level of access from day one. We also had to think beyond onboarding. What happens if an invitation expires? How should SSO users enter the platform? Should administrators deactivate users or remove them completely?

Many of these answers came through continuous discussions with engineering and Product Managers as we uncovered new edge cases.

No two organizations work the same way.

Some needed a handful of roles. Others could create dozens of custom roles with different permissions across Leasing, Maintenance, Call Center, and Administration.

Instead of defining every possible role, we designed a flexible permission system that let organizations decide what each role could view, edit, or manage.

The interface was the easy part.

The harder conversations were around change. What happens when a role is updated? What if it's already assigned to users? Should it be deleted, archived, or reassigned?

Managing fifty isn't.

Property operators were constantly repeating the same work across communities. Assigning a new Community Admin could mean selecting dozens of properties one by one. Updating a policy meant repeating the same action for every community.

Community Groups solved that.

Instead of working property by property, administrators could create a group once and use it across the platform. The same group could be assigned to users, used as community coverage, or selected as a filter in tasks, reporting, and other workflows. Adding a new property to the group automatically updated everyone who relied on it.

Maintenance work doesn't get assigned to one person.

It gets assigned to a team.

We started by designing Maintenance Teams, knowing the same foundation could later support Leasing and other operational teams. A team wasn't just a list of people. It brought together supervisors, technicians, communities, and coverage into one place.

The details mattered. A property could only belong to one maintenance team. A technician could only be part of one team, while supervisors could manage several. We also introduced skill tracking and community coverage so teams were ready before work orders reached them.

The goal was simple: make sure the right people were responsible for the right communities before AI started assigning work.

We rarely got everything right the first time.

Features changed. Requirements changed. Sometimes a conversation with engineering completely changed how we approached a problem. Other times, writing the PRDs helped us spot gaps we hadn't considered.

As the project evolved, so did the way we worked. We started by exploring ideas in Figma and refining them through regular design reviews. Later, Claude became part of our process, helping us quickly prototype different approaches, gather feedback earlier, and spend more time improving the product instead of recreating screens.

These modules were built alongside the rest of the platform as it evolved.

By the end of the project, we had established consistent patterns for bringing new organizations onto the platform, managing access, organizing communities, and setting up maintenance operations. Many of those decisions were later reused as new modules were introduced, making the product feel more consistent as it grew.