Case study
Sole engineer on a school platform used by 112 schools
I am the only engineer on Enaton, a school management platform used daily by 112 schools across Kenya. I designed it, I ship it, I operate it, and I am the one who gets called when it breaks.
- Role
- Sole engineer, design through operations
- Period
- 2023 to now
- Stack
- Node.js, TypeScript, PostgreSQL, Redis, BullMQ, React
The situation
A school in Kenya runs on numbers that have to be right. Fees owed and fees paid, who is in class, which bus a child is on, what a term report says. Most of it lived in spreadsheets, paper receipts, and the memory of whoever had been there longest.
The platform started at zero customers. It now runs 112 schools with enrolments between four hundred and sixteen hundred learners each. On the published arithmetic that is roughly fifty thousand learners and eighty six thousand contactable parents and guardians.
I have been the only engineer on it throughout.
What that constraint actually does
Being alone is usually described as a workload problem. It is really a design problem, because it removes the assumptions most engineering practice quietly depends on.
There is no reviewer. Nobody catches the mistake before it reaches somebody counting real money. So correctness has to be structural rather than reviewed. The pattern I keep returning to is removing the possibility of a class of error rather than being careful about it, because carefulness does not scale to the four hundredth change and structure does.
There is no handover. Every incident is mine, which means every incident I do not design out is a future night. That turns operability from a nice property into direct self interest, and it is remarkable how much better you design when the pager is definitely yours.
There is no shared memory. No colleague remembers why something was done. So it gets written down, in a plan while the work is in flight and a handoff when it ships. Those documents were built for a hypothetical successor and turned out to be mostly for me, six months later.
What I got wrong first
I optimised for shipping speed in the first year and treated the operational surface as something to add later. Logging was thin, jobs failed quietly, and the first serious incident was diagnosed by reading the database directly, at length, at night.
The lesson was not “add monitoring”. It was that when you are the only engineer, the ability of the system to explain itself is a feature with a higher priority than most product features, because it converts a two hour investigation into a two minute one, and you personally pay the difference.
I would now build the record of what happened before building the thing that makes it happen. That inversion is the single most useful thing this job taught me.
What that produced
The parts of the platform I would point at are not the feature list. They are the properties.
Money has one owner. Every figure derives from one place and every drill down reconciles to its headline, which is the subject of its own case study.
Work that has to happen overnight happens exactly once, is recoverable if a process dies, and can account for itself afterwards, which is the scheduling work.
Consequential actions pass through a gate rather than a permission, so authority is separated from capability and every decision is recorded rather than inferred from a status column.
Screens are built for people using them all day with somebody waiting in front of them, which turns out to be a different craft from consumer interface work.
Operating it
Migrations run against a live system while schools are using it, which means every migration is written to be safe to run twice and safe to stop halfway. Deploys happen during the working day because a deploy that has to wait for the small hours is a deploy nobody does often enough, and infrequent deploys are how you get a large risky one.
The thing I am proudest of is unglamorous: the number of incidents that require me has gone down every year while the number of schools has gone up. That gap is the entire job.
What I would do differently
I would write the operational surface first, as above. I would put a gate on consequential actions from day one rather than adding it once the need was obvious, because retrofitting a gate means auditing everything that already bypassed it. And I would have started writing decisions down at month one rather than year two, because the decisions I cannot reconstruct are all from the period before I did.
Questions people actually ask
- What does sole engineer actually mean here?
- There is no second engineer to review a change, catch a mistake, or take a call at two in the morning. Product decisions, schema design, the interface, deployment, migrations and incident response are all the same person.
- Why is there no architecture detail on this page?
- Publishing the internals of a live system with real customer data on it helps a competitor and helps an attacker, and helps nobody else. The problems and decisions transfer to any company. The implementation belongs to the client.
- Is being the only engineer a good thing or a risk?
- Both, honestly. It produces unusually strong ownership and unusually fast decisions, and it is a genuine bus factor problem. The written plans, handoffs and decision records exist specifically to reduce that risk.