MoodiBoard: generative wall art that changes with your life

The problem

Consumer art and ambient displays have never solved the staleness problem. Every digital art frame ships with a static library. You pick a few images, they rotate, and six months later you've stopped seeing them. The art becomes wallpaper

The more interesting problem is the inverse: what if the art wasn't static? What if the system knew what was true to your life in real time and the visuals responded to it?

The constraint that makes this hard: if the output changes constantly but arbitrarily, it's noise. The signal-to-output mapping has to feel coherent. Weather shouldn't just swap color temperatures randomly. A high-stress afternoon shouldn't look identical to a calm morning. The generative system needs to encode meaning, not just variation

Constraints

These shaped every technical and design decision I made

• Solo build. No team, no investors, no budget for API costs at scale. Every architectural choice had to be sustainable by one person
• The product must feel ambient, not interactive. Heavy UI defeats the point. The output is the interface; controls should be minimal and disappear
• Designing for emergent output. The designer's usual contract ("I decide exactly what this looks like") doesn't apply here. You design the system that generates output, not the output itself

Designing for emergence

The real design challenge is in the signal-to-output mapping. The question is always: when signal X changes, what should change in the image, and by how much?

Early versions surfaced the problem immediately: small signal changes produced jarring visual shifts. A cloud passing over the sun shouldn't transform the entire canvas. Getting the transitions to feel coherent, responsive without being reactive, is where most of the design iteration has gone

"Oh, so it goes with the light in my room!"

This is the kind of response I'm aiming for: delight. I want people to be moved. The meaningful feedback is when someone describes the output as theirs, as if the system understood something true about their context. That's when the signal-to-output mapping is working

The interface design follows the same principle: as minimal as possible, disappears when not needed. The canvas is primary. The controls exist to configure the signal sources and override the agent when you want to, not to be the product

The agentic dev workflow

The development process itself runs on the same agentic principles as the product. I use Claude Code as the primary engineering tool; it reads the full codebase, proposes implementations, and executes multi-step tasks including file edits, test runs, and debugging loops. Figma MCP connects the design environment directly into the build pipeline. v0 scaffolds component implementations from design specs

Before, I'd need to get someone's permission and money. Now, instead of needing two engineers, I can run a solo build by driving the architecture and product layer while the agentic tools handle the implementation layer. The constraint is the same as any delegation: you have to be precise about what you want, and you have to review what you get. The difference is the speed of iteration and the breadth of what one person can cover

• Claude Code handles the full engineering loop: implementation, debugging, refactoring, documentation
• Figma MCP keeps design artifacts live and connected; changes in Figma propagate into the component library without manual translation
• v0 converts design specs into initial component scaffolds, which Claude Code then refines and integrates into the wider system