You are reading the proof. This portfolio — two case studies, a Bio, a blog in three languages, analytics — went from a Figma file to a live site in two working days. Not because I typed faster, but because I changed who does what. Here is exactly how it was built, including what went wrong.
Figma first, always
Every screen you see here existed in Figma before a single component was written: the Home, the case-study pages, the Bio, even the hero art for each blog post. That is not nostalgia for the canvas. It is where I make the decisions that matter — hierarchy, rhythm, what to show and what to cut — and it is where I approve them, in one look, before anyone spends time on code.
The rule is simple: new page, new section, new visual language? Figma, review, approval. Only then code.
The bridge
The middle of the pipeline is BridgeUX, a tool I built that lets an agent read and write Figma from the terminal: over a hundred operations, from "give me the exact padding of this card" to "clone this glow onto forty-seven nodes" to "export this frame as PNG".
That changes what "pixel-perfect" means. The project cards on the Home were not eyeballed from a screenshot. The agent read the Figma node — 576 by 652, 32 of padding, a 21-point bold title, a 172-wide metric box, 68 of air before the image — and wrote the React component from those numbers. When I later wanted the cards a little wider, the change went the other way: adjust in code, mirror in Figma, one source of truth in each direction.
Who does what
This is the part every hiring manager actually wants to know.
The agent writes the components, wires the routes, translates the content into Spanish and Portuguese, converts thirty images to WebP, builds the favicon from the font's own glyph, generates the sitemap and the social preview, and runs the build on the server.
I decide. Which two projects out of fifteen years deserve a case study. Which single number goes on each card. That gold is the visual language and where it is allowed to appear. That the "innovative" blog post had to be replaced by this one. Every change is reviewed on the real URL, on desktop and on a phone, before I say "publish".
The principle I wrote about in another post applies to the tools too: the model interprets, the code executes — and I approve.
Nothing is done without evidence
The working rule that made two days possible is the same one I use on StratNova, the WhatsApp SaaS I am building with a team of agents: no code on my laptop, ever. The source lives on the server, the agent edits it there, builds it there, and every claim of "done" comes with proof — a screenshot of the live page, a curl showing a 200, a database row showing the analytics event arrived.
"It should work" is not evidence. "I restarted it" is not evidence. This sounds pedantic until you have watched an agent confidently declare victory over a page that renders black.
The numbers
Two days. Two case studies with thirty images. Three languages, one hundred percent translated including the hand-written notes. A Bio, a downloadable CV, a favicon, social previews, a sitemap. Privacy-friendly analytics. All of it in about 180 KB of JavaScript, with the case pages loaded on demand.
What went wrong
Because a making-of without failures is marketing:
- The favicon that would not change. An old Cloudflare rule used to redirect this domain to a Figma prototype, so browsers had cached Figma's purple lightning bolt as "my" icon. The new icon was served correctly for an hour before anyone could see it. Fix: a missing
favicon.ico, versioned URLs, and patience. - The tiny screenshots. The first version of the case galleries rendered phone screens at 172 pixels wide inside a 1,200-pixel box. It was faithful to a layout nobody had questioned. One look on the real page, one sentence from me, one commit.
- The comment that killed the stylesheet. A CSS comment containing the characters
*/inside its text silently closed itself early and disabled every rule after it. No error, just a page with no gold. Now the build checks that comments open and close in equal numbers. - The build that was not published. For an afternoon, the live site was serving a build from 15:47 while every improvement lived only on the dev URL. The agent had done the work; the deploy step had been blocked by a permission prompt nobody saw. Evidence caught it: a diff between two
index.htmltimestamps.
None of these were "AI mistakes". They were normal engineering incidents, found the normal way — by looking at the real thing.
Why this matters for a Senior Product Designer
For most of my career the distance between a design decision and a shipped screen was measured in sprints. Now it is measured in minutes, provided two things hold: the designer can specify precisely — in Figma, in tokens, in a sentence — and someone insists on evidence before believing anything.
That is the job now. Not drawing more screens. Deciding better, specifying tighter, and verifying harder. The tools finally caught up with the way I wanted to work. This site is what that looks like.