Lehmora Labs

We keep the books for tontines and schools. Never their money.

Lehmora Labs is a software engineering studio based in Douala, Cameroon. For tontines and schools, our products record who owes what, since when, and who confirmed the payment. The money itself goes from payer to beneficiary, never through us.

Tontine des Amis de BonamoussadiCycle 3, Round 5 of 8

Due
25 Oct
Closed
1 Nov, 7-day grace period
Share
25,000 XAF
Beneficiary
Esther K.
ContributorConfirmedReceived
Aïcha M.25 Oct25,000
Brice N.26 Oct25,000
Carine T.27 Oct25,000
Didier E.29 Oct25,000
Fabrice O.30 Oct25,000
Grâce A.31 Oct25,000
Hervé B.unpaid0
Expected, 7 × 25,000
175,000
Received by Esther K.
150,000
Debt of Hervé B., created at closingfollows them from cycle to cycle
25,000
Funds held by Tallyno
0 XAF

Each payment is declared by the contributor, then confirmed by the beneficiary.

Fictional example, built on the real rules of Tallyno’s engine.

Douala. A five-year-old tontine. Two hours of argument over one contribution.

At a tontine in Douala, a single doubt about one contribution was enough to cause nearly two hours of tension. The group had been running for five years. Everyone wanted a better way to follow the money, but nobody wanted to hand that money to a new app.

People often assume you have to hold the money to manage it properly. For Tallyno, I chose the opposite direction: the engine never touches the money. It records commitments, tracks contributions and repayments, and keeps a verifiable trace of what happened.

That became the rule at Lehmora Labs: bring everyday financial habits online without becoming the intermediary that holds the money. Trust can come from a system that makes the rules and the movements verifiable.

Freddy Tamwo

Founder and systems architect. Six-plus years of full-stack engineering.

Meragix(opens in a new tab)
4 open-source packages, more than 500 downloads.
lehmora-infra
9 architecture decisions written before provisioning a single server. Read the engineering notes
nui_flutter
The Flutter design system shared by the studio’s mobile apps.
Stack
Flutter, NestJS, Nuxt, Next.js, PostgreSQL, Redis, Docker.

In a tontine, the argument is never about the amount. It is about who paid, and when.

That is the one question our code must always be able to answer.

Why we don’t keep the money.

In Douala, the objection was never the technology: nobody wanted to hand the group’s money to an app. Tallyno starts from there, and Payskool applies the same principle to schools. Members pay the beneficiary over Mobile Money; families pay the school into its own merchant account. We keep the register: who owes what, since when, and who confirmed the payment.

  • No trust to ask for

    To use Tallyno or Payskool, a member or a family never hands us their money. They only need to trust the register, which they can check.

  • No funds stuck with us

    With Tallyno and Payskool, money does not pass through our accounts. If the studio stopped, no group and no school would have funds to recover from us.

  • A lighter structure

    For these two products, no customer treasury to reconcile and no funds in transit to watch. Their cost stays that of software.

Tallyno and Payskool, the register
Member, family
direct payment, never through us
Beneficiary, school
Lehmora registerwho owes what, since when, who confirmed

Funds held: none

Famsub, the escrow
Subscriber
pays
Famsubretains the funds for 30 days
released after 30 days
Owner

Funds held: yes

Famsub is the exception, by choice: when people share subscriptions, the subscriber must be protected if the service is not delivered. So Famsub retains the amount for 30 days before releasing it to the owner, with a refund possible within 7 days of joining. Building that properly took a settlement queue, a double-entry ledger and refund logic: exactly the cost the other products avoid.

The rules Tallyno does not negotiate.

Each rule answers an argument any tontine member will recognise. It is enforced by code, not by the treasurer’s memory.

  • The argument. We’re starting a new cycle and he goes before us again, while he still owes us?

    The rule. When a cycle is renewed and whenever rounds are reordered, a member in debt can never be placed before a member who is up to date.

    assertDebtorsLast()
  • The argument. My debt vanished when we restarted the cycle.

    The rule. A debt is never deleted. It follows the debtor from one cycle to the next until it is paid or written off by the group.

    carriedToGroupId
  • The argument. She already got the pot. Why is she up again?

    The rule. A member receives the pot only once per cycle. That is a uniqueness constraint in the database, not a manual check.

    UNIQUE(tontineGroupId, beneficiaryId)
  • The argument. The late fee was counted twice.

    The rule. Late fees, an upcoming option, are recomputed from scratch every night, never incremented. A job that crashes and restarts doubles nothing.

    penaltyAmount
  • The argument. Someone edited the previous cycle.

    The rule. A completed cycle is immutable. Renewing it creates a new cycle; the old one stays exactly as it was closed.

    status = COMPLETED
  • The argument. A few francs went missing somewhere.

    The rule. The pot is always share × number of contributors, in integers. There is no fraction of a CFA franc anywhere in the system.

    cycleAmount * contributorCount
  • The argument. The app crashed halfway through the payout.

    The rule. Every state change is written in a single transaction: the round, the expense and the event are recorded together, or not at all.

    prisma.transaction()

Taken from the 17 documented invariants of Tallyno’s tontine module.

Tallyno first.

Tallyno carries the studio’s thesis: the tontine, without anyone handing us their money. That is where the effort goes.

Tallyno(opens in a new tab)

Tontines and group expenses.

In developmentNestJS, Prisma, Flutter, Nuxt

  • Rounds, contributions and debts tracked group by group.
  • Each payment declared by the payer, then confirmed by the beneficiary or the group’s treasurer.
  • The group’s rules enforced by code, from round order to carried-over debts.
Tallyno screen showing the current tontine round.
The current round: who has paid, who still owes.
Tallyno screen showing the debts of the group’s members.
The group’s debts: who owes what, since when.

The studio’s other products

ProductWhat it doesHolds money?Status
Famsub(opens in a new tab)Peer-to-peer sharing of digital subscriptions, paid through escrow.Yes. Retained 30 days before release, refundable within 7 days of joining.In staging
Payskool(opens in a new tab)School fee collection, for schools.No. Families pay straight into the school’s merchant account.In development

What they share with Tallyno: the nui_flutter design system, a NestJS backend foundation and, once provisioned, a common infrastructure. The details are in the engineering notes.

Where we stand.

Updated November 2026

No product is in production yet. Famsub runs in staging; Tallyno and Payskool are in development.

Write to us

Do you invest in, build or operate community finance or education in Africa? Write to us.