Someone colors a lion with crayons, takes one photo of the page, and a few seconds later that lion walks into a jungle where other people’s drawings already live. It is in their crayon colors. It breathes, its tail swings, and its feet stay planted on the ground.
I built the first, fully working version of this in two weeks, alone, with AI coding agents. I have been a developer for 15 years, and I wrote Drawize by hand, the old-school way. This time I did not write the code. I decided what to build, looked at everything, and often said “no, this looks wrong”.
Live Coloring Book launched on 12 October 2026, two weeks after the first commit, complete: all seven worlds, coloring on screen and on paper, the classroom party screen and twelve languages. I have kept improving it every day since. In the first ten days about 1,500 people from 108 countries tried it and brought almost 3,000 drawings to life. Most came from the US, India, the UK, Italy, Brazil and Japan, and Croatia is in the top ten. On 22 October Index.hr, one of Croatia’s largest news sites, wrote about it, and an Italian teacher, Roberto Sconocchini, published a guide to using it at the classroom whiteboard.
From the repository:
- 2,178 commits in the two weeks up to launch, and 2,515 in the 25 days to today, with commits on every one of those days
- about 280,000 lines of TypeScript, C# and CSS, about 60,000 of them tests (not counting blank lines, generated code, migrations or content)
- about 2,400 automated tests
- 119 creatures in 7 worlds, in 12 languages
- a decision log of 279 numbered decisions, about 196,000 words long
Why I built it
I have been writing software for 15 years, mostly in .NET. For about eight years I have run Drawize, an online drawing and guessing game: more than 10 million players and more than 110 million drawings. I built Drawize the old-school way, by hand, with hardly any libraries besides jQuery. So I know what this kind of product costs when you write every line yourself, and that is why the speed this time still surprises me. Shortly before this project I added a small “live coloring” feature to Drawize, Pumpkin Hollow, a Halloween scene where colored creatures come alive and live together. In Drawize’s house video ads it got 1.6 to 2 times the click rate of plain coloring pages. That was my signal.
What it is
You color a page in the browser by tapping to fill, or you print it, color it with real crayons and take one phone photo. The drawing comes alive in its own colors and walks, swims or flies into a shared world with everyone else’s drawings: a jungle, a coral reef, a farm, dinosaurs, Halloween and more. A party screen puts a world on a classroom projector, and everyone in the room joins with a code. Coloring is free, with no account, no ads and no chat; some worlds and drawings are in an optional Premium subscription.
The hard parts
Making a flat drawing move, with no animators
This is the heart of the product. Every creature is one flat line drawing, and nobody animates it by hand. Our own rig tool, about 27,000 lines of TypeScript, turns each drawing into a Spine 4.3 skeleton that the official Spine runtime plays in the browser with WebGL. The player’s colored page is the texture, so whatever they color is on the animated creature. What mattered most:
Draw for animation. We generate the art, so we control the pose. Every drawing brief carries a checklist: limbs apart, each moving part closed by its own line, feet on one ground line. Every four-legged animal is drawn in the same walking pose, copied from our horse. Redrawing a picture costs cents. Fighting a bad pose in the rig does not.
One skin, not paper puppets. The first rigs had one mesh per body part. My review on day one: legs “detaching while walking, like wooden puppets… the animal is a solid area, just bending and deforming”. Now a creature is one continuous skin wherever its parts are drawn joined, triangulated with constrained Delaunay, with weights blended across each seam so hips and shoulders stretch like skin. A far leg gets its own skin behind the body, and since the drawing never showed its hidden top, a second half of the texture paints it in from the nearest colors.
Joints marked by a vision model. At first each leg’s bones split it into equal thirds, and a dog’s legs swung like a pinned paper puppet. Now Claude, used as a vision model, marks the joints on every page from a written spec: where the leg swings from the body, where it folds, the foot joint, toe and heel, which way each joint bends, and whether it is a paw, hoof, flat foot or pillar. Code checks the answer and asks once more with the problems listed.
Walks from biomechanics. Four-legged animals step in a lateral sequence, a quarter of a cycle apart, with feet planted by inverse kinematics baked into 48 keys per cycle. Each rig records its walking speed, the world moves it at exactly that speed, and a test holds each planted foot to it, so feet don’t slide. Light animals step quickly, heavy ones slowly with a deeper dip.
The rig checks itself. Every animation is played by the real runtime, 24 frames a cycle, and compared with the drawing for folds (flipped triangles that change visible pixels), hidden ends showing, and smears (a line of ink stretched past 1.65 times its width). On a fault, a fallback ladder makes the mesh finer, then tries 70 % and 45 % of the motion, then drops only that animation. If nothing is left, the rig is refused and the drawing is redrawn.
Fifteen body types are in use, from a caterpillar crawling in a stepping wave to a leaping frog. When the generator still gets something wrong, I fix it in a content editor: drag a knee, give an area to another part, or brush a skin toward a bone, and watch the re-rigged result play.
Reading crayon colors from a phone photo
A printed sheet has four solid black squares in its corners, a thin border joining them, and a QR code. Solid squares, because a crayon fills a notch, but a black square stays black under any crayon.
All reading happens in the browser, in a Web Worker. The photo never leaves the device; only the colors do. The reader:
- finds the four squares and reads the code, which names the drawing and shows which way up the sheet lies;
- maps the sheet with a homography, and on a bent sheet follows the printed border to correct for the curve;
- finds the paper’s own white across the sheet and divides every pixel by it, in linear light, so a warm lamp or a soft shadow drops out;
- reads each shape well inside its lines and takes its color in OKLab from the 70th to 90th percentile of its colored points, because a lightly pressed crayon lets paper through.
We tried snapping colors to our palette. It made the error worse (from 0.070 up to 0.109 in OKLab) and turned a brown hippo gray. A child’s crayons are rarely our palette. On a test photo of a rolled sheet, following the border cut the median position error from 1.78 mm to 0.18 mm.
The reader also measures how each shape was colored, as eight small numbers (paper between strokes, grain, direction, blotches), so every device draws the creature with crayon, pencil, marker or paint strokes. Eight numbers can say how a shape was colored, never what was drawn on it. Then the drawing is cut out like a sticker and flies into its world, where it becomes the creature.
The shared world and the party screen
Worlds are painted layers with parallax, and grayscale masks drive one shader per layer: leaves sway, water flows, windows glow. New creatures arrive live over server-sent events from ASP.NET Core 10.
On the party screen, guests color on their own device or photograph paper, and each drawing flies onto the big screen. Arrivals queue and leave 2.5 to 4 seconds apart, so every name stays up long enough to read aloud. The stage holds at most 16 creatures; with 60 drawings sent, memory stayed at about 95 to 140 MB, against 240 MB before that cap. Some school networks buffer or block streams in a filtering proxy, so after 12 seconds without an event the page reads the room every four seconds instead. Guests type nothing: names come from word lists.
Fast on a slow phone, in 12 languages
We measure on a throttled profile: a 390 × 844 phone, the CPU four times slower, 1.6 Mbit/s and 150 ms round trips. In the first version the home page’s largest paint came at 10.5 s and the world moved at 18.2 s, because the stage waited for the whole world and all thirteen creatures. Now the still picture comes first, the world moves once the creatures in view arrive, and pictures are AVIF, decoded off the main thread. Result: largest paint 2.31 s, moving at 6.81 s, and layout shift 0.00, a rule on every page.
No user-visible text is in the code; a lint rule enforces it. English and Spanish came first, and the other ten languages came on 9 and 10 October as catalog files, not code changes: 3,539 messages each. A test checks that the server and the browser format every message identically.
How the agents worked
The engineering was done by Claude in Claude Code, often several agents in parallel, each on its own branch and git worktree: 557 merges. The drawings, and later whole content batches (packaging, labeling, rigging, review sheets), were done through Codex with OpenAI’s image model. Claude kept the app code and the rig generator.
CLAUDE.md is the constitution. Every agent reads it first. My standing instruction is in it: “no shortcut is allowed to make something easier to implement”. It says when to ask me: only about money, legal, brand, product direction, pricing and matters of taste. Everything technical is theirs to decide, record and move on. Questions go into a text file in the repository, each with a recommendation and an empty ANSWER: line, and work continues on the recommendation.
The decision log is the memory. Agents forget between sessions; the repository does not. Each entry says what was decided, why, what was tried and dropped, and the numbers.
Only the code that ran. Re-rigging every creature took 40 to 110 minutes, and any generator change triggered it. Now each rig is stamped with a hash of exactly the functions it executed, recorded with V8’s precise coverage. A change that only the frog’s code runs re-rigs only the frog. Approved creatures are frozen in git.
Tests in proportion. Unit tests and the touched flows while building, a fast check at merge, the full suite in every browser once a night. That rule came from me: “I think we test way too much all the time.”
What went wrong
The walks. A sign error reversed the footfall order, so every four-legged animal did a diagonal shuffle. The pace came from leg length in pixels, so the stubby-legged hippo walked fastest in the jungle. When the sheepdog was reported as walking, I asked: “you really think this is something we can publish?” Later a “graceful” walk was merged after being compared only with its own previous version; next to the live walk it was worse, and we reverted it. Now every motion change is compared side by side with what is live.
Faked behaviours. We tried a sleeping lion made by squashing the whole drawing down, and a show-off that hops and turns. It looked lame. One side-view drawing has no folded legs or belly to show, so we keep to motion close to the drawn pose.
About 2,000 tests missed a basic bug. The day before launch, a playtester on a Pixel phone could color almost nothing. The paper allowed vertical scrolling, so Chrome took over after a few pixels of finger wobble and canceled the tap. Emulated taps in tests never wobble. Now the paper owns every touch, a tap may wobble 22 px with no time limit, and a finger rubbed across shapes colors them like a crayon.
A tiny canvas. On a 1920 × 1080 laptop at 150 % zoom, the coloring paper was 288 px square, 11 % of the screen. Each element above it was fine alone, but our screenshots used 900 px tall screens. The paper is now 448 px there, and CLAUDE.md lists real width × height pairs to check.
Agents and one machine. 115 leftover worktrees filled about 400 GB of my disk, and test runs hammered the CPU while I worked. Now worktrees go at merge and background work runs at below-normal priority.
What I learned
- Taste stays human. The agents measure very well: stretch ratios, foot speeds, percentiles. But most “this looks wrong” moments came from me, watching it move. I judge motion by solidity: seams, parts coming apart, sliding feet.
- Fix the input, not the code. When one animal walks badly because of how it is drawn, redraw it. A knee change that closed a hole on the spinosaurus folded the skin at other animals’ knees, so the spinosaurus was redrawn instead.
- Specs as text, word for word. The joint-marking spec in our docs is the exact prompt the vision model gets. When answers were wrong, we fixed the doc.
- “No shortcuts” needs a second rule. The agents took quality so literally that they over-tested and over-scoped: small features became hour-long jobs. “Fast” had to mean no wasted process, never a cheaper result.
- Write everything down. A 196,000-word decision log sounds absurd, but it is how a fresh agent avoids an old mistake.
Try it
It’s free, with no account: livecoloringbook.com. Color a drawing on your phone, or print a page, color it with crayons and take a photo. If you teach, try the party screen on a projector.
I would love to hear what breaks, especially on old phones and unusual cameras.
This article was drafted with Claude from the project’s repository, docs and git history, and edited by me, Tomislav Lombarović.