I built a Figma plugin that generates product flows directly from the codebase
Your app is the source of truth
Every product team eventually runs into the same quiet friction: no one is completely sure what the product actually looks like right now.
If you ask what the current onboarding flow looks like, you rarely get a clean answer. Someone opens the app and starts tapping through screens while sharing their phone. Someone else searches Figma for a file that might be outdated. An engineer links to a pull request that changed part of the experience three months ago. Gradually, a partial picture emerges, but it is almost never complete.
Certain screens only appear under specific conditions. Some branches depend on whether a user is signed in, what region they are in, or which experiment they have been bucketed into. Edge cases live in code paths that designers may never have seen. Over time, the gap between the “design file” and the shipped product quietly widens.
That gap is what led me to build a Figma plugin called Source of Truth.
Starting from production instead of memory
The core idea is simple: instead of reconstructing flows manually in Figma, generate them directly from what is running in production.
Most modern codebases already include snapshot testing. Whenever a UI change is introduced, snapshot files are uploaded and reviewed so engineers can see exactly what has changed visually. These snapshots are precise representations of real screens in the app. They are versioned, reviewed, and tied to specific flows in code.
Source of Truth traverses flows defined in the codebase and pairs each step with its corresponding snapshot. It then generates a structured representation of that journey and renders it directly into Figma as connected frames on the canvas. Screens are ordered correctly, branches are mapped, and edge cases appear naturally because they already exist in code.
If a flow splits depending on whether a user is authenticated, both paths appear. If a recovery process has multiple outcomes, each one is represented. What used to take hours of manual reconstruction becomes something you can generate in seconds.
Why this matters more than speed
The immediate benefit is obvious. Designers no longer need to spend time recreating flows just to understand the current state. Engineers can reference a visual map that matches what is actually shipped, and customer service agents can have a direct reference to what customers should be seeing.
But in my opinion, the more meaningful shift is alignment. When everyone is looking at a flow generated directly from production artifacts, there is far less room for ambiguity. Discussions shift away from “I think it works like this” toward “Here is exactly how it works today.” That clarity changes the quality of the conversation. It becomes easier to reason about tradeoffs, to spot inconsistencies, and to identify places where the experience has quietly degraded over time.
In a subtle way, the plugin reframes the relationship between design and engineering. Instead of design being the canonical source and engineering implementing it imperfectly, production becomes the shared ground truth that both sides can inspect.
Where this could go
The current version relies on locally collected snapshots that are passed into Figma, but the natural next step is to remove that friction entirely. Hosting snapshots on an internal server would allow flows to be refreshed directly from within the plugin, making it possible to regenerate the current state at any time.
The most interesting direction, though, is moving beyond static images. Today, snapshots render as flat frames in Figma. In the future, those images could be interpreted through a model that understands the design system and reconstructs editable components instead of screenshots. Rather than generating a picture of a button, the plugin could generate the actual button component with the correct properties applied. At that point, the boundary between design files and production begins to dissolve.
In the end, Source of Truth is less about automation and more about starting from reality. Before redesigning, before optimising, before debating improvements, you can see the product exactly as it exists and that’s a powerful place to start.