Bluedash AI Conversion

On this project it never happened, because the way the work gets made was converted. Design and frontend stopped being two sequential activities separated by a handoff and became one activity, performed by one person with Claude Code. There is no specification, no handoff meeting, no interpretation gap and no correction round trip, because the person making the design decision implements it in the same session. In ten days, between 2026-08-10 and 2026-08-19, the design became a running application: a fifteen-module Next.js frontend, a Nest.js api and a documented design system, around 651 source files and 106,000 lines, with more than 45 logged decisions and 128 change entries recording why each part is the way it is.

This case study is about that conversion. What it changed, what it made possible, and what had to be built to keep it safe on a product whose design was ahead of its documentation.

Bluedash made that concrete in three ways.

The design was ahead of the documentation. Figma canvases existed for some modules and not others, Business Brain had been supplied with zero screenshots, and the information architecture was an unsigned deliverable. A build that filled those gaps with reasonable guesses would demo beautifully and be wrong in ways nobody could find later, because a guess written into a component looks exactly like a decision once it is committed.

Speed removes the reviewer who used to catch drift. When one person designs and builds at pace, every screen is an opportunity to write a value rather than use one. Nobody is reading the diff. The drift is invisible per screen and fatal in aggregate, and a padding written into a screen is not a small mistake, it is a design question answered by nobody and now shipped.

And real supplied frames contain inconsistencies: a gap that is 20px on one screen and 24px on the next, a control drawn at two heights, a label capitalised two ways. An assistant tidies them up helpfully. Every one of those tidyings is a design decision made by a machine, in silence, against a document the product owner signed.

The second half is the machinery that keeps that pace honest, and on this project it is built around one rule: nothing enters the product that cannot name its source.

Provenance is carried in the artefact rather than in memory. Each of the design system's 126 catalogued components names the frame or export it came from, and a component extracted from a product screen is flagged in the documentation as a step weaker in provenance than one taken from a component sheet, because the first is a reading and the second is a specification. Every screen file opens by naming its Figma canvas, its frame numbers, the module research it was read through, and what those frames leave unanswered.

Where the source says nothing, the product says nothing, visibly. A module with no supplied screens got a deliberately blank route: no title, no description, no empty state artwork, because each of those would assert something about a module nobody had agreed, and the only control is the way back. Business Brain sat behind that placeholder for nine days with an owned open question against it, and was built the day its Figma canvas arrived, not before. Controls whose effect nothing evidences are drawn and left inert rather than given an invented behaviour.

Defects in the supplied frames are transcribed and catalogued rather than repaired, because repairing a drawn inconsistency is a product decision and not a build one. The exception is written down too: a defect a module's own research already calls a defect gets fixed, and where the fix would be a product decision it ships as drawn and goes on the list.

Research and code are bound by a single seam. The module registry is taken from the research folder names, the workspace navigation is generated from it, and the api throws at boot if its feature module count disagrees, so there is no path where the product and its documentation drift apart about what exists.

Around that sit the working rules, fifteen documents with the design rulebook as the one to read before building any screen. A screen never invents a visual element, and the test for whether something is a component is not whether it has been used twice but whether a second screen would want it. Every surface that can hold nothing gets an empty state in the same pass. Motion is a token chosen by what the motion does rather than by the nearest number, and a close is not the open played backwards.

The biggest gain was not the time saved, it was where design decisions get made. Judging a screen as a running interface rather than a frame changes what you notice, and most of what this project designed was invisible in the Figma: every empty state, the whole dark theme, the exits that no static file draws, the confirmation nineteen actions needed. In a handoff those either become correction rounds or they never happen, which is the specific way products ship slightly worse than their design.

The honest caveats are real. The frontend has no test suite, and while strict types, the boot assertion and two purpose-written check scripts catch the failures this workflow actually produces, that is a narrower net than tests and I would not run a project with a data layer this way. This workflow also suits one person who can hold both roles, and I do not know how it behaves with two designers and three engineers, where the handoff is also a coordination mechanism rather than pure overhead. Nothing here has been in front of a user: the conversion changed how the product gets made, not how it gets validated, and the supervision patterns the design proposes still need testing with real operators. And the information architecture is still unsigned, which is the phase gate working as designed and also a reminder that this workflow makes building fast without making agreement fast.