Kodomi began as a quiet itch. I kept returning to the same frustration—building and sharing interface ideas often felt more laborious than creative. Design tools were either too restrictive or too messy. Developer handoff was clunky. I wanted a space where designers could think in interfaces without switching between tools, specs, and explanations.

The core question was simple: what if building UI felt like sketching? What if libraries, layout, and live publishing were native parts of one unified flow, not stitched together?

I started drafting a few ideas. Sketches turned into systems. I wasn’t interested in building another editor. The goal was clarity and modularity. I wanted to treat UI components like language—composable, repeatable, and alive.

As I mapped the problem space, I looked closely at existing tools. Webflow was powerful but leaned into visual dev. Framer was elegant but performance-heavy. Figma was collaborative but not functional beyond prototypes. I wanted Kodomi to sit in a different place—between modularity and immediacy, between system and spontaneity.

I structured early goals around speed, portability, and precision. Could a user generate layouts using a prompt? Could they connect their own component libraries? Could design systems be injected live?

Building the asset manager became the first major step. I designed it to mirror the mental model of working with references—connected libraries on the left, editable structures on the right. Recents, bundles, and elements all in one glance.

Variables became essential. I introduced scoped tokens early on. Widths, margins, and fonts weren’t static—they referenced shared values. I wanted the interface to feel like a live design system you could mold in real-time.

One of my favorite details was the generation prompt field. It felt small but unlocked something big: intent as input. Instead of dragging elements, users could write “Contact page with elements from Kodomi library and Mesoki buttons.” The system handled the rest.

That led me to rethink how libraries worked. I designed Kodomi’s library system to feel more like a modular brain than a static folder. You could mix assets from iOS, Material, Mesoki, or Noque and see them blend without friction.

Styling followed structure. Kodomi doesn’t ask for visual choices upfront. It inherits color and motion from connected tokens. I made that decision to minimize hesitation. Design decisions should emerge from flow, not break it.

There were moments of doubt. Was I overcomplicating it? Was this just another tool no one asked for? But each time I used Kodomi to build something small, I felt the feedback loop I was missing elsewhere. Click, edit, publish—no lag, no translation.

I spent days fine-tuning the layer navigator. It had to feel weightless. Every interaction was tested with low contrast, keyboard-only use, and variable nesting. The hierarchy needed to disappear when not needed.

The visual tone was deliberate. Soft orange and clean greys. I avoided hard shadows and saturated indicators. Every choice aimed at reducing UI noise so users could focus on what they were making, not what they were clicking.

What I’d change now? I would invest earlier in real-world testing. I spent too long building alone. Seeing how others approach layout or libraries changed how I understood the product entirely.

Kodomi made me more precise. It taught me how systems emerge from friction, not planning. It also reminded me that tools should feel quiet. They should amplify thinking, not interfere with it.

I’m still building it. Slowly. Not chasing perfect, just following what feels right.