In Practice
Nov 6
In Building Is Designing, our white paper from earlier in 2026, we described how the design team started building iOS apps with Claude Code instead of handing off static design files. Since then, some of the work happens in Figma, some as SwiftUI prototypes in Xcode, and some as production code in the app's release builds.
That shift brought speed and put designers' hands on the code. But it also had a cost: The work was no longer visible to everyone on the team. For a company that argues design and engineering belong closer together, that was an ironic problem to have.
None of the tools we evaluated fit the process we had in mind, so we experimented with building our own.
Blueprint is a desktop app, built as a web app and packaged with Tauri for macOS, that pulls a product’s requirements and Figma designs into one structured view, and shows the team what’s done, what’s missing, and what has drifted from the plan.
Here’s the problem Blueprint solves, and how it works.
How Our Design Team Delivered Work Before AI-Assisted Programming
Our designers used to deliver detailed Figma files covering every flow, screen, edge case, and error state, along with design system documentation and component libraries. Keeping them current was a second job. One screen change meant updating every flow it appeared in, and a breaking component change meant combing through all of the work by hand.
This problem is compounded by how we work. We typically concept, prototype, and build new products, where requirements keep shifting in the early stages. Larger teams can dedicate designers to documentation. On a smaller, agile team, every hour spent on upkeep is an hour lost somewhere else.
What Changed When Designers Started Building in Code
When we started using Claude to build the front end of the apps we were designing, our designers could complete part of their work in Figma and part of it in code. Some of that was prototypes for complex interactions or animations that were easier to work out in code than to design in Figma first. Some of it was production code for release builds.
The team was building faster and moving through more rounds of iteration, which was the goal. Outside the design team, though, it became less clear what the current state of the design was.
Design was living across multiple surfaces: in Figma, code and PRs in GitHub, tickets and status in Linear, and strategy and requirements in docs and slides. Product and engineering had less visibility into the work because it was no longer all documented in Figma. We’d removed a handoff but created a visibility problem in its place.
Even within the design team, each contributor's Claude instance could see only its own part of the product. Shared markdown files and Slack kept the team coordinated at first, but as more contributors and AI instances worked on the same product, differences between what was specified, designed, and built started to add up. The glue that held the team together wasn’t built for that many hands moving that fast.
Our first fix, screenshotting or rebuilding coded work back into Figma at the end of each cycle, took about as much time as the documentation we'd been trying to avoid. The tipping point came when we were running several projects at once, and small issues started compounding across all of them. Keeping internal teams aligned and preparing slides or cleaned-up Figma boards for every client review became a job in itself.
Why Existing Design Documentation Tools Didn't Fit Our Process
We evaluated Zeroheight, Storybook with MDX, Notion, and Figma Make. Zeroheight came close. It's an off-the-shelf platform for design system documentation with some support for agents like Claude, but its model of documentation didn't match our goals. Storybook with MDX is more toolkit than product: flexible, but you build on its conventions, and every upgrade risks breaking what you've built on top.
How Blueprint Works
Glue holds things together until they move. What the team needed was a spine: one structure that everything else attaches to.
Blueprint’s spine is the product’s strategy and requirements, which the team writes and continuously updates in the tool itself. They aren’t technically a PRD, but they play the same role: the core brief that work gets assigned from. The product itself is mapped as a four-level hierarchy of Areas, Flows, Screens, and States. We standardized on those terms because when several AI instances work on the same product, they need to use the same words for the same things.
Work flows in from Figma, builds, and product management tools into Blueprint. Each screen or state is linked to its Figma frame, and any change to that frame gets updated in Blueprint and developers can connect their builds, and we’re starting to let them upload renders of the production app to archive the work alongside the designs.
Where Blueprint Is Going
We first built Blueprint to document a product that was already in design and build, using AI to generate documentation from the docs, slides, and screens we already had. When we started work on a new product, we found that Blueprint couldn’t support starting from scratch. It needed existing work to populate it.
Since then, we’ve been working on document editing so that documentation can start in Blueprint. Our latest feature generates a full map of Areas, Flows, Screens, and States in a blank project, giving design and engineering a shared starting point before anything exists in Figma or code. At its core, Blueprint is a floor plan: one layout that shows where everything belongs, including the rooms not yet built. The product’s requirements are its spine, the central structure every room connects to.
How Blueprint evolves from here depends partly on the tools around it. Figma and Linear are both building agents and product delivery features of their own. Their arrival raises a question for us: whether Blueprint’s value grows alongside those features, or whether some of what it does gets absorbed into the tools themselves. An agent running inside Blueprint, with its own MCP connections and working on a loop, is one path we’re watching.
Blueprint is an experiment we’ve run alongside our day-to-day work, and we don’t know yet whether it will last or only fits how we’re working on this set of products. But it has already changed how we decide between buying a tool and building one. Maybe that reflects where teams are now. Instead of adopting huge, complex software built to fit everyone, teams can spin up tools specific to a product, a client, or the way a group wants to work together.