Context and intent
When we started Meraklı Tosba, 'coding for children' wasn't really a category in Turkey yet. Outside of a handful of pilot workshops, there was no local product designed to introduce children to coding or algorithmic thinking at an early age. We started Meraklı Tosba to fill that gap with a real, native product.
For us, coding wasn't something to be taught as an abstract concept — it had to be a game mechanic. The child wasn't going to learn in front of a screen; they were going to learn with a real object, on a real playmat, solving real problems with their own hands. That simple intent shaped every design decision that came after.
Market timing
We launched before the children's coding category had taken shape in Turkey — the product was noticeably ahead of the market.
Physical learning
Coding wasn't framed as a 'screen subject' — it was designed as a physical game mechanic the child could touch and move.
Age range
Aimed at 6-12 year olds — the same toy had to work at different cognitive layers depending on the child's age.
Pedagogical intent
Fun wasn't the cover for something else. Learning was the natural result of the fun.
First version — a physical game kit
The first Meraklı Tosba wasn't a mobile app — it was a hands-on game kit. The box contained a robotic turtle toy at the centre, a controller board the child could load code blocks into and run, a set of physical code-block cards, story-themed playmats and a guide for parents and teachers.
Robotic turtle
The character at the centre of the kit — moves, turns and gives sound and light feedback on the mat in response to the child's commands.
Controller board
The child arranges physical code-block cards on the board and runs them on the turtle. No screen, no abstract code-writing — the program is something the child can touch.
Code blocks
Forward, back, turn, repeat, if-then — the core control-flow primitives, each turned into a tactile card the child can pick up.
Story playmats
Each mat carries a small visual story — the child's job is to get the turtle to the goal of that story by sequencing the right blocks.
Guide
A book for parents and teachers explaining the pedagogical flow. The guide was what kept the side-by-side learning meaningful at scale.
Pedagogy and safety
A children's toy doesn't get to be just 'fun'. It has to teach from the right pedagogical angle, and it has to guarantee the child's physical and electronic safety. These two principles sat behind every design decision from day one.
Pedagogical progression
Levels moved from single direct commands to repetition, loops and conditionals — abstractions introduced one layer at a time.
Learning by doing
Every block placement turned into a concrete visible result on the mat. Making mistakes was a natural step in the learning flow, not a failure state.
Electronic safety
Low voltage, sealed battery compartment, no sharp or hot parts in physical contact with the child — these were first-order design requirements.
Material choices
Every external part was specified to standards safe for materials a child might put in their mouth.
Production — the first 3D-printed batch
We produced the first batch on 3D printers rather than traditional injection moulds. That choice bridged prototyping and small-scale production for us, and it kept us out of upfront mould-tooling costs at low volumes. The product hit schools and parents with a response well past anything we'd planned for.
Rapid iteration
A design change could become a printed part in a day. The product cycle compressed in a way that wouldn't have been possible with injection moulds.
Low-volume economics
We were able to ship tens, then hundreds of kits without committing to mould tooling.
Demand signal
Early reception confirmed the product was filling a real gap. That signal is what pushed us toward planning full mass production.
The mass-production wall
As demand grew, a clear problem surfaced: the kit had a lot of plastic parts, and the cost of moving each of them to traditional moulded production sat well above both our financial capacity and the grants we had access to. The 3D printing throughput we could sustain wasn't keeping up with how fast demand was growing either.
Part density
The kit had dozens of distinct plastic parts — toy body, board, card slots, mat holders. Each one needed its own mould investment.
Funding gap
Between the R&D output built with TÜBİTAK support and the capital required for full mass production sat a real gap we couldn't bridge at the time.
The call
Once it was clear we couldn't carry production under the existing conditions, we made the deliberate decision to carry the same pedagogical approach into a sustainable format — a mobile game.
Phase two — the Flutter mobile game
We brought the same pedagogical intent into a digital environment. The mobile app was built in Flutter — feeding iOS and Android from one codebase was a critical efficiency gain for a founding-team-sized company. The child solves progressively harder puzzles on screen by dragging and dropping visual code blocks.
But the mobile game wasn't designed to replace the physical toy — it was designed to work alongside it. Through BLE (Bluetooth Low Energy), the mobile app could still connect to the turtles we'd produced; OTA (over-the-air) firmware updates meant a turtle already in someone's home could keep getting better remotely — a kind of flexibility you don't usually see in a hardware toy.
Drag-and-drop levels
Visual programming blocks the child arranges and runs; each level layers a new mechanic onto the previous one.
Progressive difficulty
Levels move from single-step commands to small problems wrapped in loops and conditionals.
BLE bridge
Code authored in the mobile app could be sent in real time to the physical turtle.
OTA updates
Firmware on already-shipped turtles could be improved remotely — rare flexibility in a consumer toy.
One codebase, two stores
Flutter let a small team feed iOS and Android in parallel without doubling the workload.
The product management lens
Meraklı Tosba taught me product management in the hardest possible shape — from zero, hardware and software together, across both technical and pedagogical scope. As a co-founder, I had to decide not just what to build, but what not to build.
Hardware + software + pedagogy
Balancing three disciplines inside the same product — the same sprint could carry a circuit-board issue, a pedagogical content review and a mobile-app build error.
Suppliers and manufacturing
Plastic injection vendors, PCB manufacturers, packaging — none of them ran on the rhythm of a software team. As a co-founder I was the bridge between those rhythms.
Budget and funding reality
Running the product build on one side while tracking TÜBİTAK and adjacent grant applications on the other was an inseparable part of the founder role.
When to pivot
Accepting that the kit's mass-production cost was beyond what we could carry, and continuing the same pedagogical intent in software, is the most concrete product-management lesson I took from this project.
Outcome and perspective
Meraklı Tosba is still talked about in Turkey as one of the most thoughtful children's coding toys ever shipped here. For us, it ended up being less a numerical success story and more a founding project — a first-hand education in what entrepreneurship actually is.
It clarified a few things for me that have stayed with me through the rest of my career: a product's success doesn't only depend on the team that builds it. It also depends on the maturity of the market, the accessibility of production infrastructure, and the timing of capital. When those don't all line up at the same moment, even a good product can find itself capped at a smaller scale. That's a lesson I learned here.
Pioneer
Launched at a time when the children's coding-toy category in Turkey hadn't taken shape yet.
Scope
Two phases — a physical game kit (toy + board + cards + mats + guide) and a later mobile companion game.
Integration
BLE and OTA bridged the mobile app to the physical toy.
Reception
Schools and parents responded well past expectations; the product is still cited as one of the best in its category.
Limit
A heavily multi-part plastic build kept full mass production above our financial capacity at the time — that limit was part of our story, not the category's.