Atlas

Twenty-eight modules, and ten nobody can switch off

Atlas is sold by subscription, so some modules open and close. The catalogue lives in the code, versioned and reviewed in diffs: a module exists only if there is code behind it. It is reconciled on every start — a new code is inserted, an existing one is never overwritten (labels the administrator edited survive), a code that disappears is deactivated rather than deleted, so the permissions referencing it do not break.

Ten modules are marked core: students, levels, subjects, payments, teachers, timetables, absences, rooms, settings, permissions. They are in every plan and nobody can cut them. That is the anti-lockout safeguard: no configuration mistake, no unpaid invoice, no support blunder can shut a customer out of their own software.

One last detail, and it matters: adding a module to the catalogue without declaring it in the routing table makes the server refuse to start. That is deliberate. A half-wired module is an open door onto data a subscription has not paid for.

• 28 catalogued modules across 6 families
• 10 core modules present in every plan and impossible to disable
• Catalogue in code, seeded and reconciled on every start
• A withdrawn module is deactivated, never deleted — the permissions citing it survive
• Catalogue and routing table out of sync = the server refuses to start
• Per-plan quotas on active students and user accounts

The Moroccan payslip, finance-act rates included

No foreign tutoring-management software issues a Moroccan payslip. Yet it is the monthly obligation of any centre employing teachers, and the one most expensively outsourced.

Atlas encodes the rates in force: employee CNSS at 4.48 % capped at 6,000 dirhams, AMO at 2.26 % uncapped, an itemised employer share, a professional allowance of 35 % up to 6,500 dirhams of gross pay and 25 % beyond with their respective ceilings, a six-band income tax scale with its deductible amounts, and a family allowance of 50 dirhams per dependant, capped at six. Everything stays editable — including the tax bands — because a finance act changes every year, and a hard-coded rate turns a scale change into a software release.

Four contract regimes coexist: permanent and fixed-term contracts on the full regime, ANAPEC contracts with no deductions at all during the integration exemption, and hourly-paid teachers on a 17 % final withholding without CNSS — the regime that actually applies to substitute teachers.

A validated payslip is frozen: the full detail of the calculation is stored at issue time, and the PDF re-reads that detail instead of recomputing. A payslip whose amount changes six months later, because a rate moved in between, is not a payslip — it is a dispute.

• CNSS 4.48 % capped at 6,000 MAD, AMO 2.26 % uncapped, itemised employer share
• Professional allowance of 35 % or 25 % depending on gross pay, with ceilings
• Six-band income tax with deductible amounts, family allowance 50 MAD × 6 maximum
• Four regimes: permanent, fixed-term, ANAPEC exempt, hourly-paid at 17 % final withholding
• Every rate editable, tax bands included
• Validated payslip = frozen calculation; the PDF re-reads, it never recomputes
• Net amount in words, and the leave balance carried onto the payslip

Leave, computed under Moroccan law and never stored

The annual entitlement is one and a half days per month worked, increased by another day and a half for every five years of seniority, capped at thirty days. Atlas computes it on the fly, at every lookup. No counter is stored: only the previous year's carry-over and manual adjustments are.

That choice is not a technical affectation. A stored counter drifts — a corrected hire date, a cancelled leave, an adjustment, and the displayed balance stops matching the real entitlement without anyone noticing. Recomputed, it is correct by construction.

The leave types are those of Moroccan law and practice: annual, CNSS sick leave, in-house paid sick days, article 274 absences (marriage, birth, bereavement), 98 days of maternity leave, hajj, unpaid leave. Religious holidays are estimated on a tabular Hijri calendar, accurate to within a day, and flagged as estimated until the administration confirms the date — uncertainty is shown rather than hidden.

Finally, a request is approved from a link received by email or WhatsApp, without logging in: a single-use token, purged the moment a decision is made. A director who has to open a piece of software to approve three days of leave does not approve them, they call back later.

• 1.5 days per month, +1.5 days per five-year band, capped at 30 days
• Balance recomputed at every lookup — no counter that can drift
• Types seeded per centre: annual, CNSS and in-house sick leave, article 274, 98-day maternity, hajj, unpaid
• Religious holidays estimated on the Hijri calendar, flagged as such until confirmed
• Approval via a single-use link, no login, purged after the decision
• The balance flows automatically onto the payslip

Every action touching money is scored, and some raise an alert

In a centre taking cash, the risk is not a system outage: it is the quietly granted discount, the deleted payment, the price lowered after the fact. Atlas ships an engine that watches every financial action and assigns it a risk profile.

The thresholds are explicit and in the code: a 30 % price reduction is suspicious, 50 % is critical; more than ten actions in five minutes flags abnormal entry; amounts above 5,000 dirhams warrant attention, above 10,000 they are critical; an operation between 10 pm and 6 am is flagged as out of hours; five deletions a day or fifteen a week raise an alert, as does 50,000 dirhams of cumulative reductions over seven days.

In parallel, the audit trail keeps the full history of changes with author and timestamp. The difference between the two is sharp: the audit trail answers "who did what", the financial engine answers "is this worth looking at now". A centre has no time to read a log; it needs the three lines worth a question pointed out to it.

• A per-user risk profile, built from their financial actions
• 30 % reduction suspicious, 50 % critical
• More than 10 actions in 5 minutes: abnormal entry flagged
• Operations between 10 pm and 6 am flagged as out of hours
• Daily and weekly caps on deletions and reductions
• A timestamped audit trail with author, running alongside the alerts

Rights are set per permission, not per role

A centre's software is used by the director, the front-desk staff, the teachers, sometimes an accountant. Giving them four fixed roles means choosing between opening too much and closing too much.

In Atlas, the source of truth is the individual permission: tables of roles, permissions and grants, all scoped to the centre, adjustable from a dedicated screen. Legacy role letters no longer govern access — with one deliberate exception, the director, who keeps full access on both the browser and the server side.

Verification happens on both sides: the browser's router reads the permission each screen requires, and the server re-checks it on all of its routes. That is the only honest configuration — a check that exists only in the browser protects nothing, it hides a menu.

A handful of routes stay open, deliberately and on the record: Meta's WhatsApp webhook, verified by token; the public site's read-only endpoints; the student portal, protected by a student token; and the super-administration routes, protected by a dedicated key.

• Roles, permissions and grants per centre, adjustable from the console
• Checks on the browser AND the server, on every route
• The director keeps full access, explicitly and on both sides
• Each screen declares the permission it requires
• The few token-less routes are listed and protected otherwise
• Each centre's data isolated by automatic scoping

WhatsApp, because email in Morocco goes unread

Foreign software chases parents by email. In Morocco a parent's email address is neither read nor always known; their WhatsApp is. Atlas makes it a first-class channel, not an optional integration.

The centre sends an arrears reminder to one parent or a whole list, confirms a payment, welcomes a new student, attaches a file, checks a number exists before writing to it, and works from message templates instead of retyping. Sends go through a queue and failures are kept — a message lost without a trace is worse than a message not sent.

On top of that, something no competitor offers: polls and educational games delivered over WhatsApp, with their results and statistics. A centre that keeps its parent group alive keeps its families.

• Arrears reminders one by one or in bulk, straight from the overdue list
• Automatic payment confirmations and welcome messages
• Message templates, attachments, number verification before sending
• A queue and retained failures — no send lost without a trace
• Polls and educational games on WhatsApp, with results and statistics
• Payment receipts rendered as images, readable directly in the conversation

An advisor that actually counts, not a polite summary

Atlas ships a strategic advisor: it compares school years, projects the next one, costs out an expansion, produces a report and answers questions asked in plain language.

What sets it apart from a decorative assistant is that it counts properly. Headcounts are established from payments in the period, not from an "active" checkbox nobody ever unticks. Revenue only counts statuses actually collected. Teacher cost is reconstructed from timetabled hours multiplied by the hourly rate, plus monthly retainers. Retention is the number of students who paid in both years over the previous year's total; churned students are those who paid last year and not this one.

These definitions are written into the code because they are the whole difference between a flattering dashboard and a useful one. On the infrastructure side, several AI providers are wired in with key rotation, automatic fallback, caching and quota monitoring: the advisor does not go down because one provider hiccuped.

• Year comparison, next-year forecast, expansion analysis, strategic report
• Headcounts based on payments in the period, not an "active" flag
• Teacher cost reconstructed from timetabled hours and retainers
• Retention and churn defined explicitly, on a September-to-August school year
• Several AI providers, key rotation and automatic fallback
• Caching and quota monitoring: the service holds when a provider drops

What a Moroccan centre actually does with its days

The rest of the product comes from what generic software ignores, never having watched a Moroccan centre at work.

A centre lends books: there is a catalogue, loans, returns and subscriptions. It hands out printed material: it is assigned, tracked, and parents find it in their portal. It runs private lessons alongside groups, with their own economics. It pays expenses — rent, electricity, supplies — that have to be set against income to know whether a group is profitable. It enrols students mid-year, so amounts are pro-rated over the days actually owed. It runs referrals. It manages rooms that cannot host two groups at the same hour.

Each of these is a module, with its permissions, its screen and its place in the statistics. Added up, they are what makes a centre close its spreadsheet.

• Library: catalogue, loans, returns, subscriptions
• Handouts assigned and visible to parents
• Private lessons tracked separately, with their earnings
• Centre expenses and per-group profitability
• Pro-rata calculation for mid-year enrolments
• Referrals, tickets, real-time notifications, on-demand backups
• Rooms, capacities and occupancy conflict detection