Our software team built a side project called Kalaquo Kids — a free web app where young children describe something they want to make, and the app turns it into a 3D model they can export and print. The frontend is Next.js and React, with a Three.js viewer for the 3D interaction. The flow from the child’s perspective is simple: they type what they want to make, wait about a minute, and then a 3D model appears on screen that they can spin around, zoom into, and place alongside other things they’ve created. Behind the scenes, the app runs the description through a couple of AI steps — first generating a 2D image, then converting that image into a 3D mesh — before rendering it in the browser. The resulting geometry is deliberately low-detail and chunky, which works well for 3D printing on consumer printers since simpler shapes tend to slice and print more reliably. One of the more interesting challenges was making the 3D viewer perform well on the devices kids actually use. The STL export runs entirely in the browser with no server round-trip, so a kid can go from typing a description to having a printable file in about two minutes. The child is the author of the whole creative process — they’re the toy maker, and the AI is just the toolbox. No accounts, no data collection, no analytics. Free. https://kids.kalaquo.com/ — feedback welcome.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (1)
The chunky low-detail mesh is the part that actually survives a cheap FDM bed. I still see kid-generated STLs fail the first print: a 1.2 mm wall that the slicer thins to one extrusion, a tiny connector that snaps, or an STL that looks fine in the viewer but has no flat base. Geometry is necessary, not sufficient — wall, clearance, and orientation still decide whether the file prints after the browser export. luphra.com is where I send those files when I need a real printability judgment after the kid-to-STL step. Honest last-mile note.