Lovable shipped Design Systems. It still can't see your brand
By The WAALEE Team · · 4 min read
Lovable shipped a real feature this cycle: Design Systems, a way to define a component library, tokens, and styling rules once and reuse them across every project in a workspace. It's a legitimate answer to the "how do ten different Lovable projects end up with one look" problem. It's not an answer to the question most people actually have the first time they open a design system feature: where do the real values come from. Read the docs closely and that gap is still there, it just moved one layer deeper.
What Design Systems actually does
A Lovable design system lives as its own project inside your workspace. Release it and Lovable generates a design-system.json schema (tokens, component catalog, variants, props, examples) plus rendered markdown docs for components, tokens, and library guidelines, with a version bump and a git commit each time. Connect another project to it and updates flow through automatically instead of getting redone by hand on every new build. That's a real fix for a real problem: teams running five or six Lovable projects who were previously re-explaining their palette in every single prompt.
Three ways in, and none of them read a live URL
Per Lovable's own docs, a design system starts one of three ways: built from scratch inside Lovable, imported from an existing npm package or public Git repository, or assembled from PDFs, markdown, screenshots, and written instructions you hand it directly. Notice what's missing from that list. There's no "paste your live site" option and no Figma connection, nothing that reads real computed colors, type, or spacing off a page that already exists. If your brand's actual hex codes and type ramp only live in a website nobody ever turned into a package, none of the three intake paths gets you there without a manual step first.
- From scratch: fine if nobody's decided your brand yet, which is rarely true by the time you're building the third version of an app.
- npm package or Git repo: only works if your tokens are already coded, versioned, and public, or you're on Enterprise, which unlocks private npm wrapping.
- Docs and screenshots: Lovable infers values from what you hand it, so the accuracy ceiling is exactly however precisely you described a color in a PDF.
The docs are honest about the ceiling
One line in the documentation is worth sitting with: an existing project can't be converted into a design system. Once you've built an app and it already looks the way you want, you can't just point Lovable at it and say "make this the system." You have to go back to source, pull the values out by hand, and feed them back in through one of the three intake paths. That's not a bug, it's a reasonable scope decision for a first release. It also means the feature solves distribution, one system reused across many projects, without solving origination, where the first project's look actually comes from.
Read the values off the page you already have
If the real version of your brand only exists as a live, rendered website (built years ago in something other than Lovable, or handed off by an agency with no source files left), the fastest path into any of Lovable's three intake methods is the same move: extract the actual computed colors, type scale, and spacing off the rendered DOM first, then upload that as the documentation Lovable ingests, or wire it into the from-scratch flow as real numbers instead of a guess. That turns "docs and screenshots" from a lossy description into an exact one.
Three approaches to getting real tokens into a system an AI builder can reuse:
- Lovable Design Systems: Reuses one system across a whole workspace once it exists. Three intake paths (scratch, npm/Git, docs), none of which read a live URL directly.
- OpenDesign: Agent-native alternative built around a single DESIGN.md plus tokens.css and manifest.json, compiled into an immutable versioned system. Same shape of problem: it still assumes someone already wrote the tokens down.
- WAALEE: Paste a live URL and get the real colors, type scale, and spacing back as W3C tokens in seconds, ready to hand to Lovable's docs-and-screenshots intake, or anywhere else, as exact values instead of a description.
None of this is a knock on shipping Design Systems. Reuse across projects is a real, overdue feature, and being upfront that an existing project can't just become the system is more honest than a lot of "one-click" pitches in this space. The point is just to know which half of the problem it solves. Distribution and origination are different jobs, and Lovable just fixed the first one.