MagIA: Bringing Children’s Drawings to Life
MagIA is a startup I founded around a simple idea: take a child’s hand-drawn character and turn it into an animated figure they can play with. The goal is to get kids drawing on paper again, away from the tablet, and then reward that creativity by bringing their drawing to life.
You can find the startup’s landing page at magiaworld.com.
At its core, MagIA runs a drawing through a computer-vision pipeline — figure detection, segmentation, automatic joint/pose placement, and finally rigging — to produce a character that can move. This write-up covers how I approached the project: the application and tech stack, the AI pipeline behind the animation, and the product and distribution thinking behind turning it into a startup.
Chapter 1. The Tech stack
Coming from mechanical engineering to robotics, I skipped the entire usual introduction to html, css, javascript and general app development. To me, this is one biggg fuzzy area. Not just in the languages, but everything that is involved with it.
As the focus of this project is mostly focued on learning about scaling a product into market. I wanted to keep the application simple (and scale the pipeline later). Therefore I wanted to avoid as much as possible everything around dev-ops. By keeping the requirements as light as possible (keeping most if not everything about the app in-app), the idea was twofold: 1. IP is both very expensive and bearocratic. This goes against the focus of the project. If I want to make sure no-one copies my product, I would have to include verification procedures, such as codes, specialized QR and IP or something. This is needlessly complicated. Therefore I will drop all that once the product grows enough where it is worth giving it a thought. 2. I am probably going to make mistakes in my pipeline. Therefore I want to avoid as much as possible the vunerabilities exposed to the user. 3. I want to avoid the complexities of having a large distributed network. Therefore no kubernetes, helm or any dev-ops. Again the focus is on creating a tech business not the tech stack. 4. I want to costs from servers as much as possible. The app isnt guaranteed to work. And if it does, I want it to be profitable as early as possible. Just to feel like an achievement. Having to pay to host the distribution of images in and out + other is simply not worth it.
For this reason, the app will be developed such that it can be ran offline. The following will therefore be required:
A frontend A backend
As the animations are likely much easier (and the scaling later), if I use something such as godot. The focus will be on developing a frontent that can communicate with godot. And then handle the animations via Godot.
Main Plan:
- Frontend ->
- Backend -> Python (data processing) + godot (animation)
Animated Open World Background
The first playable experience should feel like an open world generated from the user’s drawings and GenAI production. The animated background is not just decoration — it becomes the game world itself, with the scene dynamically built from drawing inputs, style transfer, and procedural generation.
This gives a strong proof of concept: the user’s page drawing can be turned into an animation directly in the app, with the same sketch becoming part of the world and story.
From the same idea, animations and stories can be created in two ways: directly in the page drawing itself, as shown by the demo_dancing_stickman.gif, and later as separate reusable assets, as shown by boy_waving.gif. That means a story can start from a simple sketch on the page and then scale into a full set of characters and game assets that are later assembled into a custom world.
Chapter 2. Initial Scaling
In order to invest the product, I had to make sure I wasn’t just a mad man, but that people actually were interested in such as product as I am. To do this I had several focus groups in several countries:
- Liectenstein
- Austria
- Switzerland
- France (Toulouse)
- Italy (Pisa/Florence)