MDS Studio
SHIPPED
April 2026
My Role
Solo build
Scope
IA · Prompt design · Build · Deploy
Scale
Full MDS token and component library
THE PROBLEM
Prototypes took days. The bottleneck was coordination.
Producing an on-brand prototype at Thrivent means coordinating a designer, a developer, and the design system documentation. Even a straightforward landing page takes days of back-and-forth before anything is testable. The bottleneck isn't capability. It's coordination overhead. A product manager with a clear concept still waits for a designer to translate it into a layout, and for a developer to make that layout functional, all while staying compliant with the MDS component library, token values, and brand guidelines.
That delay pushes user feedback later in the process, when changes are more expensive and momentum is harder to recover.
Innovation Week gives every employee a week to build anything, no briefs, no approval chain. I used mine on a question I'd been sitting on: is a design system's own documentation enough to drive AI generation that actually looks right? Not almost right. Right enough to put in front of users.
THE INSIGHT
The documentation existed. The structure didn't.
Thrivent's design system is thoroughly documented: component specs, design tokens, spacing rules, typography scales, color palettes, voice and tone guidelines. But none of it existed in a form an AI could consume. It was scattered across internal websites, wikis, and tools, written for humans who could fill gaps with judgment. A model can't. Making the system AI-legible meant closing every gap a human would have papered over.
So the first phase of the build produced no code at all. I gathered specs from across Thrivent's internal ecosystem and restructured them into markdown files with explicit token values, component contracts, and design rules. A button spec in my version doesn't say "primary button." It specifies the exact hex value, border radius, font size, padding, and hover state. Deciding what the model needed to know, and in what form, was the central design problem of the project. Everything downstream inherited its quality.
Those structured specs became the system-level context for the Claude API:
No Figma access
No component library imports
No build toolchain
The constraint turned out to be the advantage. The same properties that make manual prototyping slow, fixed tokens, bounded components, approved patterns, are exactly what make AI generation reliable. Bounded choices mean fewer hallucinated designs. A design system is already a set of rules about what a model shouldn't invent. It just has to be written down that way.
THE TOOL
Type a description. Watch the page build itself.
MDS Studio is a web application where you describe the page you want and it generates a fully styled, responsive, brand-compliant HTML page, streaming element by element. The output includes Thrivent's actual header and footer, correct component patterns, proper token values, responsive breakpoints, and interactive states with hover and focus behavior.
A syntax-highlighted source view lets you inspect the generated code. Brand photography from Thrivent's DAM can be toggled on, pulling from a curated set of 28 images with contextual descriptions that steer the model toward appropriate selection. Output opens as a standalone page suitable for user testing tools like Dscout: concept to testable artifact in one prompt.
THE BUILD
Documentation first, code second.
Monday went entirely to input design, not code. I'd planned on GitHub Copilot, but IT hadn't provisioned VS Code on my machine, so I switched to Claude, which I already knew. The whole day was finding, extracting, and restructuring the design system specs into AI-ready context.
Tuesday was the build, in Claude Code. First generations, errors, an architecture rethink, more errors. When I hit dead ends, I moved to Claude.ai to reason through the problem, then back to Claude Code to implement. I shared a fake PRD with the team, a "Find a Financial Advisor" results page, so they'd have something concrete to test against.
Wednesday morning I deployed to Netlify and shared the URL. Within an hour our PM had prompted it into a modal confirmation flow and reported he could put it in front of users immediately: "I could quite literally take this, put this into Dscout today and go from concept to feedback probably in 3 hours."
The rest of Wednesday and Thursday went to hardening: CORS lockdown, iframe sandboxing, a custom syntax highlighter. In Claude.ai I ran a designed critique pass, four simulated domain reviewers (frontend, product, design systems, QA) each scoring the codebase 1 to 5 with itemized gaps, then took the consolidated punch list back to Claude Code. Post-critique scores landed between 4 and 4.5 across all four.
Friday morning: brand photography integration and a security rebuild. The original plaintext password was fine for early testing, but interest had grown enough that anyone with the URL and View Source could reach the tool, so I moved the app HTML server-side, loading only after a serverless function validates the password.
Friday afternoon was the demo: three slides, then live generation in front of the audience, including a prepayment flow for a product still in underwriting.
TRUST CALIBRATION
Calibrating trust in AI output.
Generating output is the easy part of AI work now. The design problem is deciding how much of that output to trust, and making sure the interface never claims more confidence than the system has earned.
MDS Studio is honest about its own limits. The output uses MDS token values and follows MDS component patterns, but it is not React components importing from the actual library. A generated button has the right color, height, radius, font, and hover state, but it's a styled HTML element, not an MdsButton. That distinction matters for production and is irrelevant for user testing, so the tool is framed as a prototyping surface, not a production pipeline. Overclaiming fidelity is how internal tools lose credibility in a regulated org.
I had tested the same discipline two months earlier, from the consumer side: SubScan, a subscription scanner designed and shipped at a one-day Chicago hackathon, live at subscan.mosullivan.design. The interface was the fast part.
The design work was the trust decisions:
The model defaulted to dark mode and color-coded stat numbers, red for high spend. I shipped light mode and black numbers. A financial tool earns trust by staying neutral; color implies a verdict on your spending.
Cancel buttons appear only where a confirmed cancellation URL exists. A button that leads nowhere destroys trust faster than no button.
The prompt's exclusion logic is encoded domain knowledge: drop the recurring charges that look like subscriptions but aren't, installment loans, gyms, in-person services. Ten years in fintech is what knew where that line sits.
Statements are processed client-side and never stored, which makes the privacy claim on the upload screen a fact.
Both builds make the same move. Constrain the model with encoded domain knowledge, MDS token contracts in one, fintech exclusion rules in the other, so the output can be trusted for its stated purpose. Then label honestly where it can't.
WHAT THIS PROVED
Documentation quality is now testable.
A design system's documentation, restructured into explicit token values and component contracts, is a sufficient input for AI-driven prototype generation. No component source code, no Figma files, no build infrastructure. But raw documentation doesn't work as-is. Someone has to decide what the model needs, extract it from wherever it lives, and structure it in a form the model can use reliably. That's a design problem, not an engineering problem.
If specs are precise enough for a human developer to implement correctly, they're precise enough for an LLM. If they're not precise enough for an LLM, they may not be precise enough for a human either. The AI becomes a documentation quality signal.
Reflection
What this work actually required.
+
Input design was the project: the first day produced no code, just the information architecture that made every generation after it reliable.
+
Trust is designed at the edges: the honest fidelity limits, the withheld cancel buttons, and the exclusion rules are what separate a demo from a tool people act on.
+
Constraints are an asset in AI generation: bounded token values and component contracts are why the output looks right instead of almost right.
+
Production stopped being the bottleneck, so judgment is what's left: what to feed the model, what to constrain, and what to refuse to ship.