Skip to content
msomi School Management
About

Built in Nairobi, for the way Kenyan schools actually run

Not an international product with a currency setting changed. A system designed around CBC and KCSE, a three-term year, TSC numbers, M-Pesa and parents on feature phones.

Most school software sold in Kenya was designed somewhere else. It arrives with one curriculum, monthly billing, a parent portal that assumes a smartphone, and a support desk eight time zones away.

Schools adapt around it. They keep a spreadsheet alongside for the things the system cannot express, run a second process for the transitional cohort, and continue phoning parents because the portal never reached them. The software is not wrong, exactly. It was simply built for a different set of assumptions.

What we decided to build instead

Msomi started from the assumptions that actually hold in a Kenyan school. That a school may be teaching CBC and preparing KCSE candidates at the same time, and needs both to be correct. That the academic year has three terms and the budget follows them. That the teacher record has to carry a TSC number. That fees arrive by M-Pesa and have to be matched to a learner. That a large share of guardians do not use a smartphone, and that these are disproportionately the families where contact from the school matters most.

None of those are exotic requirements. They are simply the ones you get right by default if you build here, and retrofit badly if you do not.

The idea underneath all of it

A school's problem is almost never a shortage of information. It is that the same fact is recorded in several places by several careful people, and those places disagree — so no report can be fully trusted and every question takes a morning to answer.

Msomi's whole proposition is one record per learner, one per member of staff, and every process reading from those rather than from a copy. Accurate reports, current dashboards, informed parents and a shorter end of term all follow from that. They are consequences, not features.

How we work with schools

We would rather tell a school that Msomi is the wrong fit before a demo than have them find out three months into a subscription. When a school asks which plan they need, we sometimes recommend the cheaper one. When a school wants to leave, their data exports in a format they can use.

That is not generosity. A school management system is a decade-long relationship, and the only version of it that works is one where the school is not trapped.

02 How we build

Six things we will not trade away

One record, not eleven copies

Every feature reads from the same learner and staff record. We add nothing that requires a school to maintain a parallel list, because the parallel list is where the trouble always starts.

Nobody excluded by their handset

Every notification has an SMS equivalent. A product that only reaches parents with smartphones reaches the wrong parents.

Configured, not assumed

Curriculum frameworks, grade boundaries, admission number formats and fee structures are things a school defines. We do not decide what an A is.

Your data leaves whenever you want

Every list exports to Excel on demand, without a support ticket. A vendor confident in their product has no reason to make leaving difficult.

Built for the room, not the demo

Registers and marks work offline, because the signal in a classroom block is not the signal in the front office. Software that only works in ideal conditions gets abandoned.

Separation we can prove

Msomi runs many schools on one platform. The boundary between them is enforced where data is read, not in the page that displays it.

Next step

See Msomi running on your own school data

A demo takes about forty minutes. Bring a class list and we will set up your frameworks, levels and grading while you watch — so you are looking at your school rather than ours.

Or try it first — the Trial tier gives you a full term, free, with every module unlocked.