Short answer
RaftLabs built Sekou, a French-first school management platform and LMS for K-12 schools in French-speaking West Africa. A six-person team (two frontend and two backend engineers, QA, and a PM) delivered attendance, marks, fee collection, and role-based portals over about six to seven months. Sekou supports 4,000+ students per school.
Engagement
The Sekou engagement
- Client
- Sekou, an EdTech startup building school software for French-speaking West Africa
- Decision-maker
- The co-founders, who grew up in the school system Sekou is built for
- What it is
- A French-first school management platform and LMS for K-12 schools, with portals for administrators, teachers, students, and parents
- What we owned
- The product build: attendance, marks and results, fee collection with payment integrations, role-based dashboards, and the admin tooling behind them
- Team
- Two frontend engineers, two backend engineers, one QA engineer, and one project manager
- Engagement model
- A fixed-scope project with a dedicated team
- Duration
- About six to seven months
The situation
In most of the world, a school's attendance, marks, and fees live in software. In the French-speaking West African schools Sekou was built for, they lived on paper registers and in people's heads. Every term brought the same problems: human error in records, staff out of sync with each other, inventory nobody could track, and curriculums rebuilt by hand every year.
Sekou's co-founders grew up in that system and felt those problems first-hand. They also saw why the obvious fix didn't work. The established LMS products were built for English-speaking schools, and adapting them to these schools meant fighting the product at every step.
Nothing was about to break, and that was the problem. Without a platform built for these schools, nothing would improve either, and the paper systems would keep holding progress back.
An LMS is not a strategy. It is a delivery mechanism. The failure mode for school platforms is familiar: a system that cost real money and months to roll out, now used to store documents nobody reads. Sekou's co-founders had lived the paper-register version of that failure. They needed software built around how their schools are actually organised, not a generic platform fighting the school at every step.
RaftLabs put a six-person team on the build. The hardest lesson came early: French-first wasn't a translation job. The schools are structured differently, and the product had to be built around that structure. We also talked the client out of one feature that would have sunk the timeline. The platform we shipped supports 4,000+ students per school.
starting point
From paper registers to one platform
The goal was to digitise and consolidate how a school runs, in the language and structure these schools actually use, not to hand them a translated copy of a Western LMS.
- Attendance and marks recorded on paper and reconciled by hand
- Coordination between administrators, teachers, and parents ran on people, not systems
- Fees tracked manually, with errors and slow follow-up
- Inventory and school resources hard to track and maintain
- Curriculums rebuilt and updated by hand every year
- The LMS products on the market were English-first and assumed a different school structure
- Attendance and marks captured in one system, with support for corrections after they're finalised
- Separate dashboards for administrators, teachers, students, and parents, laid out around each role's everyday tasks
- Fee management with payment integrations, feeding the school's own records
- One platform for the school's records instead of registers and spreadsheets
- A French-first product built around how Francophone schools are organised
- A consistent codebase built to take later features without a rewrite
The hard parts of building for a different school system
Designing for a school system that isn't ours
The brief said French-first. The team first read that as a language requirement. It turned out to be much more. The schooling system in these countries is structured differently, with different parts and different ways of grouping students, terms, and results. It wasn't a language thing.
Translating an English-first product would have left the data model wrong underneath. We designed the records, labels, and workflows around how these schools actually run. Our engineer's own takeaway: we understand schools intuitively from our own lives, and that intuition doesn't carry over.
Attendance and marks that change after they're final
Attendance and marks look like simple records until real schools use them. Sessions overlap. Scores get reworked after they've been finalised. Attendance gets corrected days later. The same data passes through several stages, from draft to finalised to reported, and each stage handles it differently.
The shortcut was to build the happy path and patch edge cases as schools reported them. We didn't. We designed the code to handle all the major cases and most of the minor ones up front, including overlaps and changes to finalised records, so a correction doesn't break a report downstream.
Fee collection and payment integrations
Fees were one of the hardest systems in the build. Collection had to connect to external payment integrations and land cleanly in the school's own records, with the same care for edge cases as attendance and marks: partial payments, corrections, and records that must reconcile.
We built fees on the same consistent data patterns as the rest of the platform, rather than as a one-off module. That kept the system predictable for administrators and gave the team a base to extend later.
The class scheduling feature we recommended not building
Semester class scheduling caught us off guard. It was in the original plan and looked like a normal feature. After research, it turned out to be a genuinely hard problem: fitting teachers, rooms, classes, and constraints into a working timetable. Paid products exist that do nothing else.
Building a full scheduler inside the normal project scope wasn't feasible without wrecking the timeline. We pushed back and simplified class scheduling instead. That's the most important scope call on the project. A school platform that ships beats one that stalls on a problem an entire product category exists to solve.
Proof
What the build delivered, and what this page can't claim
Figures as recorded at the time. No long-term learning-outcome measurements were available for this review.
| Result | What changed | Period or context | Evidence and limitation |
|---|---|---|---|
| Scale | 4,000+ students supported per school | Teachers record attendance and marks without paper registers; parents see progress without waiting for the end of term | Project-recorded, as recorded at the time |
| Time to launch | 16 weeks from concept to launch | A six-person RaftLabs team; one recommended feature (full class scheduling) was deliberately cut to protect the timeline | Project-recorded, as recorded at the time |
| Early beta | 25% boost in school community connections | Parents saw day-to-day progress instead of end-of-term reports | Early beta figure, as recorded at the time. Not a long-term outcome measurement |
the build
What we built
Every portal was laid out around what each role does most often, so the common tasks sit where people look first.
Teachers record attendance and marks without paper registers
Teachers mark attendance, enter marks, and manage class materials in one place. Corrections are part of the flow, not a support ticket: a finalised mark or attendance record can be reworked without breaking the reports built on it. Students get their own dashboard for assignments, marks, and materials.
Parents see attendance and marks without waiting for the end of term
Parents get a dedicated portal with their child's attendance, marks, and school announcements. Instead of waiting for the end-of-term report, they can follow progress as the school records it, in French.
Administrators run fees and records from one panel
Administrators manage enrolment, fees, and school records from a single admin panel. Fee collection runs through payment integrations and lands in the school's records, replacing manual tracking and the errors that came with it.
French-first, built around how these schools are organised
The product was built in French from the start, and its structure follows how Francophone West African schools are organised, not how English-speaking schools are. Terminology, grouping, and results match what teachers and administrators already use.
The lesson
Scope the school system, not just the software
If you're building school software for a market outside the English-speaking world, the thing most teams miss is that the school system itself is part of the scope. We treated French-first as a language requirement at the start. It wasn't. The schools are structured differently, and that difference reaches the data model, not just the labels.
Everyone on a project team has been to school, so everyone thinks they already understand how schools work. That's exactly why it gets skipped in discovery. Before you design a single screen, map how the target schools group students, run terms, record results, and handle corrections. And check early whether any feature on the list is really its own product. Timetabling usually is.
How it runs
- React
- Four user types (administrators, teachers, students, and parents) needed their own dashboards. Shared components let the team build four role-specific layouts without four separate front ends.
- AWS Lambda
- School usage peaks around term starts, exams, and fee deadlines, then drops. Serverless functions scale for those peaks without paying for idle servers the rest of the year.
- Hasura
- A GraphQL layer over the school's data gave every role's dashboard the records it needed, with access rules per role, without hand-writing an endpoint for each view.
- TypeScript
- Attendance, marks, and fees move through several stages, and a silent data mismatch would reach a parent or a fee record. Typed data contracts catch those mismatches during development.
Common questions
RaftLabs built Sekou, a French-first school management platform and LMS for K-12 schools in French-speaking West Africa. It covers attendance, marks and results, fee collection with payment integrations, and separate dashboards for administrators, teachers, students, and parents. A six-person team (two frontend and two backend engineers, QA, and a PM) built it over about six to seven months.
Existing LMS products were built for English-speaking schools and assume a school structure that doesn't match Francophone West Africa. The mismatch goes beyond language: how students are grouped, how terms run, and how results are recorded all differ. Adapting a generic platform means fighting its data model. Building custom let Sekou's structure match the schools from day one.
Sekou's engagement ran about six to seven months with a six-person team, and the earlier record shows a first launch within 16 weeks. Timeline depends on scope more than anything else. Attendance, marks, fees, and four role-based portals are a substantial build. Adding a full timetabling engine or national exam integrations would extend it considerably.
Semester class scheduling turned out to be a hard optimisation problem, fitting teachers, rooms, and classes into a working timetable under many constraints. Paid products exist that do only that. Building one inside the normal project scope wasn't feasible, so we recommended a simplified version. It kept the core platform on track instead of stalling on a problem that deserves its own product.
The edge cases. Sessions overlap, marks get reworked after they're finalised, and attendance gets corrected days later. The same record passes through draft, finalised, and reported stages. If the system only handles the happy path, every correction risks breaking a report. We designed Sekou's code to handle the major cases and most minor ones before launch.
Yes, for any school system that the big LMS vendors don't fit well: non-English markets, different grading structures, or local payment methods. The lesson from Sekou applies directly. Map how the target schools are actually organised during discovery, before designing screens. See our eLearning platform development service and K-12 software page.
Related work
More work for education and African product teams
3,500 field staff completing training every day
Eris Lifesciences' EMS Connect reached 3,500+ daily users averaging 30 minutes a session, with offline access for field reps.
Web3 rewards for African creators, no seed phrase
Nandi gave African fans on-chain loyalty rewards behind custodial wallets, so nobody touches a wallet extension.
48,100 minutes of tracked music practice
TuneClub, a music learning platform, logged 48,100 practice minutes and moved to recurring subscription revenue.