Roles, equity, and member rates

The question this page answers

People new to Syndik8 often ask “how do I make someone a renter?” There is no renter role to assign, and “renter” is not a checkbox either. The answer has two parts: you decide whether the person holds equity (a share count), and separately which billing scheme they’re on. Neither lives in the role dropdown. This page explains why the design works that way.

Three independent axes

Every member of a syndicate has:

A role (admin, member, or viewer) that controls what the member can do. It decides whether they can invite others, finalise bookings, edit the asset, see other members’ financial detail, book at all, and so on. See the role capability matrix.
An equity status, captured as an integer share count. shares > 0 means the member is an equity holder; shares = 0 means they’re a non-equity member. Equity status drives ownership-weighted decisions: how maintenance costs are split, who pays cash calls, and the majority-of-shares threshold used by votes. See Shares and Equity member.
A billing scheme: the named member rate that controls what the member pays. It decides the dues amount, the dues interval, and any modifier applied to the asset’s base rate.

Changing one axis has no effect on the others. They are three orthogonal dimensions.

Why three, not two

Earlier versions of these docs described two axes (role and rate) and treated “Equity” and “Renter” as the two billing-scheme names that fully captured equity status. That conflation hides a real distinction:

Equity status is about who the asset belongs to. It survives a billing-scheme rename, a rate change, even moving someone to a custom scheme. It’s the number used by maintenance-expense distribution, cash calls, and votes.
The billing scheme is about what someone pays this month. Two equity members with identical share counts can still be on different schemes, such as a founder on a discount or an instructor on an in-kind dues arrangement.

Conflating them leaves no clean way to say “Anne is a 1-share equity member on the Founder scheme; Bob is a 1-share equity member on the Standard scheme”. With three axes, you can.

The cases that make this concrete

Any combination is valid. A few illustrative ones:

Role	Equity (shares)	Billing scheme	When this happens
`member`	1 share	Standard	The common case: a partner who bought in, pays monthly dues, flies at the base rate.
`member`	0 shares	Renter	A non-equity member who pays for usage but doesn’t hold any of the asset.
`member`	0 shares	Standard	A non-equity participant on the same dues + rate as everyone else, e.g. a friend the syndicate has welcomed without selling a share.
`admin`	1 share	Founder	The founding member on a discounted founder scheme; admin powers because they help run the syndicate, equity because they bought in, founder scheme by negotiation.
`admin`	0 shares	Standard	An admin who runs operations but doesn’t hold any of the asset, common in club setups where the chair isn’t a co-owner.
`member`	3 shares	Standard	A member who bought multiple shares and gets a proportionally larger weight in cost splits and votes.

Nothing in the system prevents any combination. The finance layer reads the billing scheme; the cost-split layer reads shares; the permissions layer reads the role. None of them looks at any of the others.

Why not make “renter” its own role?

It would be a tempting shortcut (one dropdown instead of three), but the design resists it for three reasons:

The set of billing schemes is open-ended. A syndicate might run Standard, Renter, Instructor, and Founder schemes side by side, each with different dues and modifiers. If rate were a role, every syndicate would want custom roles, and the system would drift towards a per-syndicate permission editor, which is a large surface area and a high risk.
Equity status is its own thing. A non-equity member who pays the Standard rate is just as valid as one who pays the Renter rate. Folding equity status into a “renter” role would deny that case.
Roles map to capabilities, not prices and not ownership. The three roles (admin, member, viewer) are the right granularity for capability. A “renter” role would have the same capabilities as member; it would be a label masquerading as a permission level.

Keeping the three axes separate means the member role stays small and well-understood, the billing scheme layer can evolve freely, and equity status remains a clean integer the cost-split and voting code can rely on.

What this means for how you talk about your syndicate

Language drifts when three concepts are orthogonal. A few habits the docs follow, and which are worth adopting in conversation within your syndicate:

“Equity members” = members with shares > 0. Not the same list as “members on the Equity scheme”; schemes are named labels, not the source of truth.
“Renters” is a billing-scheme label, not a category of people. If you mean non-equity members, write “non-equity members” or “members with no shares”.
“Our admins” is a role statement; “our equity members” is an equity statement; “members on the Founder scheme” is a billing statement. They are three different lists, and a single member can be on all three.
When you promote someone to admin, you are not changing what they pay or how much they own. When you move them from the Standard scheme to the Renter scheme, you are not changing their role or their share count. When you change their share count, you are not changing their role or their billing.

In the app, role is set on the Edit member dialog; share count is on the same dialog as a separate field; billing scheme is on the member’s row under Members. Three controls, three concepts, no implicit coupling.