
Trust should feel human and visible, not hidden behind policy language or insider access.
Public homeHelping each other. Building wealth. Properly governed.
Helpmekaar is a community-driven stokvel platform for invite-led members who want disciplined investing, emergency protection, and visible rules.
New members join by invite or governed onboarding, not anonymous self-registration.
Money, support, and governance steps stay understandable before deeper detail appears.
One sign-in resolves the right member, governance, or rails surface after authentication.
Visible rules
The public front door should explain the entry model, the governance boundary, and the next safe step without making anonymous visitors feel like they are already inside Helpmekaar.

Trust should feel human and visible, not hidden behind policy language or insider access.

New members continue through invite or governed onboarding. The public route should not imply open anonymous self-registration.
Returning member, governance, and rails actors all start from one bounded auth route before Helpmekaar resolves the correct signed-in context.
Sponsor, committee, trio, auditor, and rails work only appear as named duty switches after sign-in, not as hidden admin power.
Next safe step
Use sign-in if you already belong here. Use invite-led onboarding only if you are continuing a governed entry path.
Helpmekaar does not use open anonymous self-registration, and member, governance, and rails context only begin after the auth handoff resolves safely.
How Helpmekaar Works
The public route should make the member journey, the duty boundary, and the route-ownership model easy to scan before a visitor commits to sign-in or invite continuation.

Helpmekaar starts with the right front door, then keeps member, governance, and rails duties visibly separate.
Existing actors sign in. New members join by invite or governed onboarding, not through open anonymous registration.
Helpmekaar should never blur returning actors with new invite-led entrants. The public route keeps the handoff visible so people do not guess whether they belong in sign-in, onboarding, or a protected route.
This keeps trust high before the session resolves into a member, governance, or rails route.
What Your Money Is Doing
The public explanation should show that liquid value, invested value, and pooled value are not the same thing. That honesty matters before members ever see wallet totals inside the app.
For money that is available now or moving toward payout.
Rand Wallet is the everyday movement layer. Funding outcomes, approved credits, release completions, and ready-to-withdraw value land here before the product implies that cash can leave immediately.
Members should read this as the liquid layer, not as a summary of every other pool.

Members should understand where money sits and what it can do before a route implies cash is already free to leave.

Liquid, invested, pooled, and governed value stay visually separate so members do not confuse total value with direct cash.
Support When Life Happens
The support story should show what is true now, who owns the next step, and how recovery works. Sensitive moments should feel dignified, not vague or improvised.

Help should feel dignified and concrete, especially when a member is already under pressure.

Support paths should show state, owner, and next step clearly instead of collapsing into vague reassurance.
Support when life happens
Entry Rules
Members, governance-duty holders, and rails actors all sign in through one bounded auth surface. Invite-led onboarding stays explicit, and role separation stays visible once the session resolves.
FAQ / Trust Centre
Trust grows when the visible rules, the support path, and the entry model can be read without insider knowledge or vague marketing language.

Trust grows when the visible rules, the support process, and the governance path can be read without guessing.
No. New members continue through invite or governed onboarding. The public home should not suggest open anonymous self-registration.
Yes. One sign-in surface resolves the correct actor context after authentication.
Yes. Member context still comes first, and duty work opens as an explicit switch.