The Knowledge Lived in People, Not the Process
Two content design hires were approved before I took the role. On paper, the solution was obvious: fill the headcount, give more teams content support. I didn't fill them.
At MoonPay in early 2025, 8+ teams were actively shipping UI. One or two had dedicated content design support. The rest were on their own — designers guessing at copy, engineers shipping whatever was in the mock, PMs not thinking about content at all. Filling two more seats would close the gap for two more teams. Six would still ship without coverage.
The staffing gap wasn't the real problem. It was masking a deeper one. The rules everyone needed were already written — eighteen months of excellent documentation, specific and structured and right. They just lived in documentation nobody opened mid-flow. The content function's bottleneck wasn't expertise. It was access.
So the question wasn't how do we hire faster. It was how do we put expertise we already have into every designer's hands, at the moment they actually need it.
Having dedicated content support creates a false reality. Designers focus on the UI and leave the words to someone else. PMs don't think about content. Engineers ship whatever's in the mock. But half the experience is the words. Understanding what you're doing on a screen comes from language more than layout. Every team without content support ships subpar work.
You can solve that with headcount. But headcount doesn't scale in a startup, and it doesn't fix the underlying problem.
The Rules Were Already Written
Voice and tone. Button label conventions. Error message patterns. Heading hierarchy. Accessibility text. All of it specific, well-structured, and right. The problem was where they lived.
Fragmented across documents. Repos people had to go looking for. Nobody does that. Designers don't stop mid-flow to look up whether a button should say "Submit" or "Save changes." They guess. They're not lazy, they're busy. The path of least resistance is whatever sounds right in the moment.
The rules existed. The knowledge was codified. It just wasn't accessible in the moment it was needed.
So the question became: how do you take rules that already exist and put them in people's hands at the exact moment they need them?
A Weekend and a Custom GPT
I'd been experimenting with custom GPTs for a while. We had a complete writing system, codified and well-documented. What it needed wasn't more content design hours — it was a delivery mechanism designers would actually use.
I spent a weekend structuring the rules into a custom GPT with expansive project guidelines. Voice and tone. Button labels: verb-first, max three words, specific over generic. Error messages: constructive, blame-free, always "what happened" then "what to do." Heading rules, body text, empty states, form labels, accessibility guidance. All of it.
The MVP was ready by Monday. I started testing — uploading screenshots of production screens, pasting Figma designs, asking for audits. One of the first screens I threw at it was a fiat balance education modal that had been a point of contention internally. Too copy-heavy, concepts that were hard for users to grasp (approval rates, funding methods, balance mechanics), and legal ambiguity around fee claims that nobody had flagged. I didn't love the screen. I wanted to see if the GPT would catch what I was seeing.
The response wasn't a vague "looks good" or a list of nitpicks. It was a structured, ten-point audit — grounded in the exact rules I'd given it.
“How is this reading against our content guidelines?”
It wasn't just checking words against rules. It was doing six distinct types of work simultaneously:
Rules-based auditing
Measuring reading level, tone compliance, redundancy against specific codified standards. Perfect recall of every guideline.
Structural critique
Questioning information hierarchy, reframing around user motivation rather than product features.
Concrete rewrites
Not just "change this" but why, with Grade 7-appropriate alternatives. Teaching while reviewing.
UX escalation
Flagging that the problem isn't just copy but screen structure.
Risk flagging
Legal and compliance callouts marked as dependencies, not afterthoughts.
Prioritised actions
A scorecard and "fix these four things first," so designers know where to start.
The traditional model: a content designer picks up work as an IC, but only for the team they're embedded with. The other six teams either got no feedback at all, or got it just before release, causing bottlenecks, rework, or confused customers. This gave every team a structured audit, instantly, on demand. The expertise that used to reach two teams now reached every team. The pattern-matching was handled in flow. The judgement calls — brand intuition, political context, taste — still needed a human. But humans were no longer spending their time on pattern-matching.
The Bet
The tool was producing work as good as the previous process — and in many cases, better. Every designer got access to the same standard, in the moment, without waiting for someone else's availability. That changed the staffing math.
The 2 approved hires were the immediate budget. The forecast plan was bigger — as the design org scaled, content design would have grown with it: multiple senior hires over time, more headcount, more cost, and the same underlying access problem.
I built an org chart for the SVP of Product. Showed where content was needed across the 8+ teams shipping UI. Showed the trajectory if we staffed this the way every other org staffs it.
Then I made the case for not doing that.
If we kept hiring our way to coverage, the function would be substantially larger and substantially more expensive. I bet on the alternative: a tooling-first content function. Same expertise, multiplied. Designers faster, more autonomous, less dependent on someone else's bandwidth. The quality floor rising across teams that never had content support.
The bet was: capabilities close the gap. Headcount doesn't have to.
The SVP backed it.
The Hard Conversation
The strategic call was easier than what came next.
The 2 approved hires got reallocated — one redirected to higher-leverage content systems work, the other cancelled. The tool had absorbed what the second role was supposed to do. The plan wasn't to abandon content design. It was to democratise access first, set a solid foundation through tools, and then hire intentionally for people who would think about content systems rather than brute-forcing IC review work.
Systematising expertise doesn't replace content designers — it extends their reach. But framed badly, it reads as "we don't care about the words anymore, we're just using AI." The opposite was true. I cared about content enough to want every team to have access to a superior standard of it, not just the two lucky enough to have a dedicated person.
This is the uncomfortable reality of systematising expertise. The people closest to the knowledge can feel threatened by making it more accessible, even when the goal is to amplify their impact. People who establish the rules for how these tools are used become more valuable, not less. But that requires a shift in identity: from "the person who does the work" to "the person who defines how the work gets done."
What Actually Changed
I piloted the tool with a few high-agency ICs who were already using ChatGPT to improve their writing. When I gave them a standardised GPT grounded in our actual rules, they welcomed it immediately.
It didn't take long before people stopped saying "this isn't finished yet, the copy is still lorem ipsum, this needs a content pass." Designs came to review with well-written, consistent content. Patterns solidified across teams.
The teams that had never had content design support became consistent too. Small, fast-moving platform teams with a history of inconsistent output were now hitting the same standard as everyone else. The quality floor rose across the entire org.
A simple governance layer kept things honest. Before anything shipped, an async content check. The tool did the pattern-matching; the human came in at the end with the judgement that couldn't be automated.
Quality went up. Speed went up. The dependency on a single person's bandwidth went to zero.
But the tool had real limits.
What It Couldn't See
The custom GPT was text-in, text-out. You'd paste copy or upload a screenshot, and it would review in isolation. A button label that says "Continue" might be fine on a checkout screen and wrong on a destructive action. The GPT couldn't know the difference. It had no awareness of the component being used, the hierarchy of the screen, or the sibling text around the element it was reviewing.
And it couldn't act on its own suggestions. It could suggest "change 'Submit' to 'Save changes'," but someone still had to find that text node in Figma and update it manually.
What if the system could see the canvas? What if it understood the component, not just the words?
That question led to a Figma plugin. The same content design ruleset, but embedded in the designer's actual workflow.
The rules never changed. The delivery mechanism evolved three times. But the deeper question — who writes the rules the tool enforces — only got answered properly when I built the third one.
Tools Enforce. Teams Author.
Most content tools come with a voice baked in. You can usually tell by the third interaction — there's a register, a rhythm, a default that bleeds into whatever you write with them. Use them long enough and your product starts sounding like the tool.
That's the wrong shape for a governance tool.
A team's content rules aren't defaults. They're choices: this is how this product talks, this is what we capitalise, this is what we never say. The tool's job isn't to introduce its own preferences alongside those choices. It's to apply the team's choices everywhere — across surfaces nobody has time to manually review.
So the plugin has two layers. A craft baseline that's true regardless of product — clarity, accessibility, blame-free errors. And a precedence rule for everything else: when the team has written project rules, those rules win. The tool's built-in defaults yield. When the team hasn't written rules, the plugin doesn't make them up — it applies craft baseline and stays out of the rest.
It also doesn't suggest a change when the existing copy is fine. If the text works, the right answer is "this works — ship it." Not "here's another option." A tool that suggests something every time drifts a product's voice over time, regardless of whether the individual suggestions are good.
Strong opinions belong with the people. The tool's role is to enforce those opinions consistently — not invent its own.
The Principle
Same expertise, multiplied. Take knowledge that lives in someone's head (or documentation nobody opens), systematise it, and put it where people actually work. The team stays lean. The quality goes up. The people who defined the rules become more valuable, because now they're shaping a system that scales, not reviewing strings one at a time.
And the tool that scales those rules has to stay out of the team's voice — applying the team's decisions, not its own.
This worked for the words. But words are just one layer of design. What about layout decisions? Component choices? Spacing hierarchies? Platform conventions?
