What a good genealogy tree must handle
Genealogy is the screen that proves whether the software was built for real networks. At 500 members almost anything works. At 50,000, the same screen decides whether your support team answers questions or apologises.
Search must work in both directions
Uplines search downward to find a member’s position. Members search upward to understand who introduced them. Both need member ID, name and phone search, with the path highlighted rather than the whole tree rendered.
Lazy loading, not “load everything”
A tree should load level by level on demand. Rendering 50,000 nodes at once is a design mistake, not a performance tuning problem.
Spillover must be visible
Members need to see whether a downline member was personally sponsored or spilled over. That single distinction prevents most support tickets in binary and matrix plans.
Permissions and privacy
A member should see their own tree, not the entire company network. Admins see everything, with role-based limits for staff who only need one leg.
Exports for audits
- Full tree export with sponsor, position and join date.
- Leg-wise volume snapshot at a given date.
- Member count per level for payout reconciliation.
Mobile behaviour
Pinch-zoom, tap-to-expand and a “jump to me” control are essential. A tree that only works with a mouse is a tree that distributors will not use.
Disclaimer: this is product design guidance for software teams, not a guarantee of business outcomes.
