Kokozi Smart IoT Learning Platform
Project Overview
Kokozi is an interactive learning platform for children in South Korea, built around a connected device. Learning activities run across the device and the web application, so the platform has to keep hardware in the field and software in the browser in step with each other.
The client ran an engineering group of around thirty people. Boffin Coders supplied one developer on a twelve-month contract, working inside that team.
Our Scope
Backend services and the admin frontend. The system was built as NestJS microservices communicating over Kafka, each service owning its own MongoDB database. Requests out to the connected device were carried over MQTT.
The Architecture
Three decisions shape a platform like this, and they are worth spelling out because they are the difference between a system that survives its second year and one that does not.
Kafka for service-to-service messaging
Services publish events rather than calling each other directly. A service can be slow, restarted or redeployed without the services around it failing — the messages wait. In a product with hardware in the field, where you cannot take the whole platform down for a release, that decoupling is what makes routine deployment possible.
A database per service
Each service owns its own MongoDB instance and no service reads another's data directly. This is the part teams most often skip, and skipping it produces a distributed monolith: the deployment cost of microservices with none of the independence. Owning the data is what lets a service change its schema without a coordinated release across the platform.
MQTT to the device
Connected hardware is not a browser. It has less memory, an unreliable connection and a power budget, and HTTP request-response suits none of that. MQTT is a lightweight publish-subscribe protocol built for exactly those constraints — small message overhead, a persistent connection, and delivery guarantees that survive a device dropping off the network and coming back.
The admin frontend sits on top of the same services, giving the client's team a way to see and manage what the platform is doing without a developer in the loop.
How It Ran
Requirements came through the client's Jira board on two-week sprints. Our developer worked their process rather than ours — their board, their standups, their release cadence, their definition of done.
That is deliberate. A dedicated developer is only useful if they are inside your team rather than beside it. We do not run a parallel process, we do not ask a client to adopt ours, and we do not put an account manager between the developer and the people they work with.
How It Ended
The contract ran its full twelve months. The client then hired an internal engineer for the role and we handed over.
That is the intended ending. A dedicated developer covers work that exists now, while a permanent hire is found, or through a stretch when the roadmap is ahead of the team. When the hire lands, the engagement should end - and it should end tidily, with the code and the context already in the client's hands, because it was always in their repository and their process.
When This Kind of Engagement Fits
An open role that is taking longer to fill than the work can wait for. A service or a feature that needs building while the existing team keeps the platform running. A specific gap - backend, mobile, frontend — inside a team that is otherwise complete.
It fits less well where a whole product needs owning end to end, or where the client has no engineering process for a developer to join.
What We Are Not Claiming
We did not build Kokozi. Around thirty engineers did, across several teams, and one of them was ours for a year.
We have no production figures to publish. Our developer worked against staging, so any throughput, device count, or uptime number on this page would be invented. We would rather leave the section empty.