Forking out of — and merging — families

A Sahidha family isn't forever-fixed. Children grow up and want their own books; two households sometimes genuinely become one. Two operations cover this: fork (one member leaves, taking their finances into a brand-new family of their own) and merge (two whole families combine into one). Both are built on the same principle that runs through all of Sahidha: ownership is individual — your accounts, holdings, and transactions are yours, whichever family they currently sit in.

Forking: one member becomes their own family

Any active member can fork themselves out from Settings. It's self-service — no admin approval step — with one guard: the only admin of a family can't fork (it would leave the family with nobody at the wheel), and guests can't fork at all.

What goes with you:

• Everything you own — your accounts, transactions, investments, insurance, and their history. Ownership never changes hands; the rows simply now live in your new family.
• Entities you manage — an HUF or business you look after moves with you, accounts and all.
• Wards — any managed person you're the guardian of (a parent whose finances you handle, say) comes along too.
• Your personal things — API tokens, device logins, social handles.
• Your budgets and categorization rules — copied across and remapped onto your new family's categories.

What stays behind: everything the rest of the family owns, and shared family fixtures (contacts, others' budgets and rules).

And one thoughtful touch: forking automatically creates a kutumb linking your old family and your new one — so any in-flight IOUs or shared visibility between you and the people you just left don't go dark overnight. Leave it, or keep it, as suits the family.

Merging: two families become one

Merging is deliberately the heavyweight operation, with a consent gate to match. Here's the shape of it:

1. Two admins agree, together. One family's admin starts the merge and enters the other family's admin email; that admin then types their own password on the same screen. Nobody can merge a family into theirs unilaterally — it takes both admins, in person.
2. A brand-new family is created. Neither family "absorbs" the other: both families' data is deep-copied into a fresh third family, and every member's login moves there. Both former admins are admins of the new family.
3. Duplicates are tidied. If both families had a "Groceries" category, the merged family gets one, with all transactions remapped onto it. Ownership of every account and holding stays exactly with the person it always belonged to.
4. The originals are frozen, not deleted. Both old families become dormant — invisible, untouchable, but intact — serving as the complete pre-merge backup.

Undoing a merge is possible precisely because of that freeze: a platform-level revert deletes the merged family and revives both originals exactly as they were, with everyone's login pointed back home. (The trade-off: anything entered after the merge is discarded by a revert — it restores the pre-merge world, not a mixture.)

Availability

Forking is live today. Merging is built end-to-end but still being validated against production-scale data, and is switched off until that completes — you'll see the option appear in Settings when it's enabled.

Which one do you actually want?

You want…	Reach for
To see a relative's shared accounts without combining anything	A kutumb — read-only, per-account, leave any time
To move out with your own finances	Fork — self-service, takes what's yours, links back via kutumb
Two households genuinely running one set of books	Merge — both admins consent, reversible via the frozen originals

Most extended families thinking about a merge actually want a kutumb: the handful of genuinely shared accounts visible to the right people, and everything else kept separate. Merge when the households are truly one; link when they're merely close.