Kokozi Smart IoT Learning Platform
Need the same stack on your project? Hire React developers in India or NestJS developers.
Planning a platform like this? See how we build web applications. Running an agency? We build them under your name as white-label web apps.
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, which we integrated through RabbitMQ, while the services talked to each other through Apache Kafka.
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.
This is how a dedicated development team placement with us runs, whether it is one developer or several.
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 Our Engineer Delivered
Twelve months of backend services and the admin frontend, working inside the client's own engineering group of around thirty: NestJS microservices over Kafka, a MongoDB database per service, and the MQTT messages out to the connected device, integrated through RabbitMQ, all shipped through the client's sprints and release process.
The platform's production figures belong to the client and sit under NDA, so this page shows the architecture and the way the work ran. We walk you through the services and the device messaging on a call.