Inviting a team member (togetha)

togetha brings rent collection, leases, maintenance, and compliance into a single admin dashboard. As customer teams grew beyond a handful of people, the need to divide that dashboard into defined lanes became impossible to ignore.

The trigger was direct: a joint session between the CTO, engineering, product, and a group of customers surfaced the gap clearly. Teams of five to fifteen people needed to invite colleagues in and control, precisely, what each person could see and do. The existing flow didn't offer that.

What togetha had was functional but shallow: enter a name and email, send an invite. No roles, no scopes, no way to say "this person handles finance only" or "this one manages properties but not billing."

For smaller teams, that was fine. For growing operations with distinct responsibilities across finance, tenancy, and property management, it created a hard ceiling.

The solution: a structured invitation flow letting admins assign a role, select which features a team member could access, and define permissions within each of those features, all from a single screen.

I started by mapping the existing invite flow against the new requirements, then reviewed how other products handle role and permission assignment before moving to UI. The flow came first. Only once that was locked did design work begin.

The first structural decision was identifying which features every team member would always have access to, regardless of role. Those became the baseline. Everything above that could be toggled and scoped by the admin.

Permissions went deeper than feature access too. Within each feature granted to a team member, admins could define what actions they could take. The goal was maximum control without the interface feeling like a settings panel.

My initial direction was a free-text input field for roles. The reasoning: since access could be defined granularly anyway, the role label was almost cosmetic. Admins could type whatever suited their team.

The CTO and I agreed to drop it. A free-text field meant inconsistency across teams and no guardrails on our end. We replaced it with a fixed roles dropdown built from roles customers had described in their own feedback, giving admins a clear starting point and keeping uniformity on the platform's side.

With the flow settled, most of the iteration happened around layout. The challenge was presenting roles, feature access, and permission levels on a single screen without it feeling cluttered.

The trickiest part was displaying selected permissions per feature clearly. Multiple layouts were tried before one held up, partly because each option had to be validated with engineering before we could commit. That back-and-forth added time but avoided surprises closer to shipping.

We validated internally with the support team, who work directly with customers and understand the workflows in practice. The QA team ran audits before the feature went live.

The final reveal.

The response after shipping was positive. Without disclosing exact figures, a significant number of customers brought additional team members onto the platform shortly after the feature went live. Scoped access gave admins the confidence to delegate, and the knock-on effect was better-managed portfolios across the board.