The Story
It started at 3 a.m. with a thought that kept me awake: what if changes to Figma variables were visible in a running web app just as directly as changes to CSS variables affect the UI? Having built a real-time app years ago, I immediately thought about that project again. What would happen if you combined that real-time layer directly with CSS variables and with Figma?
Later that morning, I sat down and built a proof of concept in about eight hours. With a bit of distance, though, I had to ask myself an honest question: who actually needs this nowadays?
After all, Figma already has Code Connect, an MCP server, and the Code Layers introduced at Config 2026. Design is being generated faster than ever, and it is being translated into code faster than ever. If design and development are increasingly becoming one AI-driven workflow, why would anyone still need to inject tokens at runtime?
In the weeks and months that followed, I thought about how to make this idea genuinely useful as AI becomes increasingly central to how we build software. Then I had a thought: what if we made all design decisions in the runtime first? What if you could test every visual change live in the running app before committing anything to a single source of truth? AI has no visual awareness of the runtime, which often means AI-generated code suffers from design drift. I figured this runtime approach might act as a live safety boundary for AI-generated UI.
That is what led me to come up with the following workflow with TokenIgnite.
TokenIgnite reads the code syntax directly from Figma. If custom properties are missing, it generates them dynamically and writes them back into the code syntax of the Figma file. When an LLM connected to the Figma MCP Server generates UI code, it receives those properties directly through the MCP Server. You simply instruct the AI via prompt to use them strictly within the component scope. TokenIgnite then injects those properties directly into the root and theme scope of the live app. This makes TokenIgnite both the foundation for AI code generation and the final validation layer in the runtime.
This creates an immediate feedback loop between humans and AI. Any design drift—whether caused by AI or human changes—shows up immediately in the browser. Teams can collaborate without hitting pipeline boundaries because, until you export, everything is simply a visual feature in the runtime. As a developer, you can step in and out whenever you want while keeping full control.
I am releasing the Public Beta now to find out whether other developers and designers actually find this useful. The plans on the homepage marked with "Planned" represent my vision for TokenIgnite, which I have already partially implemented, but your usage and honest feedback are the most important benchmark for if and how TokenIgnite will be developed further. During development, my focus is figuring out how to make the vision for TokenIgnite feel natural, fast, and both designer- and developer-friendly in today's AI landscape. If it takes off, awesome. If not, it remains a project I am genuinely proud to have built.
Public beta facts
- So far: about four months of solo product work (as of late July 2026) — from a late-night idea to a SaaS product currently in the public beta phase
- Still under active development beyond this public beta
- Sole ownership end to end: idea, concept, Branding & Visual Identity, UX/UI, design, engineering, infrastructure, and vision
- Working proof of concept on day one
- ~1K Git commits
- ~61K LOC codebase in TypeScript/JavaScript and CSS (~85% TypeScript)
- Monorepo product surface: Figma plugin, npm SDK + CLI, Express/Firebase backend, Next.js website & docs
- Real-time live sync over Firebase for token updates
- Auth, workspaces, presence; local/staging/production environments; staging/production CI (GitHub Actions); Vercel + Railway + Firebase; Changesets releases; SDK/client version gating; canary E2E; …