Case study
Merchant Flow Builder: Making the Brief the Spec
Nobody asked me to build this. The weekly pace was the reason I started. The reason I kept going was that no one could be certain the designer was building the right flow.
Built inside PayPal, and the code lives in PayPal's internal repository. Tool names here are generic and the interfaces are not reproduced.
What was unclear
The handoff was a Slack message, and there was no way to check it.
A product manager would describe the flows a merchant needed in a message or a set of meeting notes. The designer would go find what they believed was the matching section of the checkout guide and build from that. Nothing in the process closed the loop between what was asked for and what got built.
The cost landed in two places. Time, because finding the right reference and assembling the flows by hand was most of the work of preparing a package. And risk, because nothing in the process verified that the section the designer found was the section the product manager meant. On a weekly sprint across a 38-merchant program, a loose handoff is not a small tax.
What I built
Two tools, one pipeline.
The goal was not to make the manual steps faster. It was to remove the step where a person guesses.
A browser brief form. No install, no server. It captures the merchant, the contact, the meeting date, and each flow being requested. Every flow request carries a direct link to the matching section of the checkout guide rather than a typed description. On submit it saves a standalone brief, sends the team an email, and puts structured JSON on the clipboard.
A Figma plugin. It reads that JSON, scans the merchant's screen audit page, assigns the screen roles, resolves the requested flows against a library of 17 supported payment flows, and assembles the flow page: merchant screens cloned and resized, PayPal placeholder frames deep-linked back to the guide, handoff markers, section headlines.
How it fits together
The link is the thing that travels.
PayPal, 2026. Browser form, Figma Plugin API, Claude Code and Cursor.
The decision that made it work
Links, not words.
The reference format inside the brief is a Figma node link, not free text. That one choice is what turns a brief into a specification. There is no text to parse, no shorthand to interpret, and no version of the guide to go looking for. The plugin resolves the link or it fails loudly, which is the behavior you want.
It also changed the deliverable. Because every placeholder frame carries the link it was built from, an engineer or a product manager opening the file later can get back to the source without asking me. The time savings were a consequence of fixing the accuracy problem, not the thing I set out to do.
What I had to work around
The tooling was not ready either.
I built this early against Figma's MCP server, before it could read a full file. That ruled out the approach I wanted, which was to let the model look at the merchant's file and work out the structure. Instead I wrote my own scheme for identifying frames and instances so the plugin could find its way around a file it could not be told about.
That is the part I would redo now. The capability landed later, and a version built today would be shorter and less clever. I would rather have the version that shipped than the elegant one that did not exist yet.
How I built it
I designed the system. Claude Code and Cursor wrote most of the implementation.
The form is plain HTML and JavaScript with no framework and no server behind it. The plugin runs on the Figma Plugin API. I am not going to describe myself as the engineer here. What I did was specify the pipeline, decide the data contract between the two halves, and iterate on the output until it was something a designer would accept without cleanup.
That is the same work I do in Figma. The difference is only where it lands.
What changed
Most of a day became 10 to 15 minutes.
Building a merchant's full set of checkout flows by hand took most of a day. With the pipeline it takes 10 to 15 minutes, across the 38-merchant program. I recorded video tutorials covering install, the form, storage, and browsing the library, and published the whole thing to the internal company GitHub so another team could fork it.
The honest ending: it was adopted and in active use when my contract finished, and I handed it to another designer to broaden. It was not fully scaled before I left. I would rather tell you that than claim the whole organization was on it.
- 15 minPer merchant, from most of a day
- 17Payment flows supported
- 38Merchant program