MicroTribe: giving a savings group a ledger everyone can see
Savings accounts, loan accounts and member-to-member transfers for a small closed group pooling its own money — replacing the single paper notebook that one person keeps and everyone else has to trust.
MicroTribe is a ledger for a closed group of members who already know each other and pool their own funds. It is not a bank, does not take deposits from the public, and does not move real money — the group handles cash itself, and the system records it. There are no investment plans, promised returns or referral structures.
- SECTOR
- Community finance
- MODEL
- Closed-group ledger
- STACK
- Laravel
- TEAM
- 2 Members
- STATUS
- LIVE
The notebook problem
Small savings groups are one of the oldest financial arrangements there is. A set of people who know each other contribute regularly to a common pool, and members borrow from it when they need to. Self-help groups, rotating savings associations, community funds — the same structure under many names, and it works because everyone in it can hold everyone else accountable.
Almost all of them run on a notebook. One member keeps it. That single fact produces every problem these groups have.
One person can see everything
The record keeper knows every balance. Everyone else knows only what they are told, which is an uncomfortable arrangement among equals.
Disagreements cannot be settled
When a member's recollection differs from the notebook, there is no second record to check against. The dispute becomes personal, and in a group built on relationships that is the expensive kind.
Interest is calculated by hand
Loan interest across varying dates and part-repayments is genuinely fiddly. Arithmetic errors accumulate and are found late.
The history is one object
Lose the notebook and the group loses its entire record. Some groups have collapsed over exactly this.
Checking means asking
A member who wants to know their own balance has to contact the keeper. That small friction means most members do not check, which is how errors survive.
These groups do not need a bank. They need the notebook to be visible to everyone at once.
A ledger, not a payment system
The scope decision came first and shaped everything after it. MicroTribe records what the group has agreed; it does not hold or move the group's money. Members settle in cash or through their own bank accounts exactly as before, and the system is the shared, authoritative record of what happened.
That boundary keeps the software simple where simplicity matters and keeps the group in control of its own funds. It also keeps everyone on the right side of a line that matters: a system that held members' money on their behalf would be a regulated activity in most jurisdictions, and building one for a group of neighbours would have been the wrong answer to their problem.
Balances are tracked as internal units against each member's accounts. What they represent is the group's own pooled money, and the group decides what a unit is worth when it settles.
Three account behaviours
Each member holds accounts that behave differently, and the differences are where the accounting rules live.
Regular member contributions accumulating over time. A member's savings balance is their claim on the pool, and it must always be visible to them without asking anyone.
Amount borrowed, repayments made, interest accrued and outstanding balance. Interest is computed by the system rather than worked out by hand each cycle.
Movements from one member to another within the group. Two accounts change together or neither does.
The ledger has to balance, always
For most applications, a data inconsistency is a bug to fix on Monday. Here it is the end of the product. The group's only asset is agreement about who has what, and a ledger that has ever been wrong is a ledger nobody trusts again.
So transactions are written as balanced entries rather than as balance updates. A member-to-member transfer is not "reduce A, increase B" as two operations that might partially fail; it is one atomic entry that either applies completely or not at all. Balances are derived from the entries, so the sum across the group is always internally consistent by construction rather than by periodic repair.
Corrections work the same way. A mistaken entry is reversed with an offsetting entry rather than edited away, so the history shows what happened and what was corrected. In a group where members can see each other's activity, a record that quietly changes is worse than one that visibly shows a fix.
What the platform covers
Engineering notes
A small application by size. The constraints come from what it records, not from how much traffic it takes.
Laravel
Database transactions and a mature migration path matter more here than raw throughput. A group of this size will never stress the framework.
Balanced entries
Every movement is written as offsetting entries inside a database transaction. Balances are derived, never edited directly.
Immutable history
Entries are never deleted. A correction is a new reversing entry, so the record shows both the mistake and the fix.
Member visibility
Members reach their own position directly. Removing the need to ask the record keeper was the point of the whole exercise.
How the team built it
GegoSoft engineers use Claude Code as standard daily tooling. On a ledger the valuable use is test coverage over arithmetic: interest across irregular repayment dates, part-payments, reversals, and concurrent transfers touching the same account. Those cases are tedious to enumerate by hand and are precisely the ones that produce a balance nobody can explain.
The decision to keep the system a ledger rather than a payment platform, and to make corrections visible rather than silent, were the team's. Every change passed normal review before merge.
Common questions
Is this banking software?
No. It is a shared ledger for a closed group of members recording their own pooled savings and lending. It does not take deposits from the public, hold members' money or move funds. Building a system that did any of those would be regulated activity, and it was not what this group needed.
Can GegoSoft build software for a self-help group or cooperative?
Yes. The pattern is common — a group tracking contributions, loans and balances among known members. The engineering care goes into the ledger, because a group whose records have ever been wrong is a group that stops using the software.
What does virtual money mean here?
Balances are tracked as internal units representing the group's own pooled funds. Members settle in cash or through their own bank accounts as they always did; the system is the shared record of what was agreed, not a payment rail.
Why does the transaction history keep corrections visible?
Because in a group where members can see each other's activity, a record that quietly changes is worse than one showing a mistake and its fix. Errors are reversed with offsetting entries rather than edited away.
Do you build other financial or ledger systems?
Yes — crowdfunding with multiple payment routes, lead qualification for a lending operation, and pharmacy billing where every transaction has to reconcile. The common requirement is a ledger that balances and an audit trail that holds up.
Running a group fund on a spreadsheet?
Tell us how your group tracks contributions and loans today. The useful question is usually not what features you want, but who currently has to be asked before anyone knows where they stand.
Start a conversation See all case studies