The toolchain works for the people who found it. It doesn't work for the people who haven't. Adoption happened through Slack posts and demos which is a fragile distribution model. Further investment wouldn't be features it'd be a discovery layer: an internal landing page, onboarding docs, a request channel for the next systemic gap. The next step: the toolchain exists because it was the means to a ship date, it was never resourced as a product itself. Its maintenance and evolution rest on one person, and design systems don't stand still. The right next step isn't more heroics, it's using the adoption and time-savings data the tools have generated to make the case for resourcing them as a real internal product with an owner. Tools that prove their value should graduate from initiative to infrastructure.
Case Study 03 | Developer & Design Tooling
Role
Designer + Developer
Year
Nov 2025 - Present
I'd just shipped the Projects vertical on IES: an AI-native, agentic experience whose design components I'd built as a self-serve system for other verticals to inherit. Then I was brought to the manufacturing team with a mandate: deliver the same class of vertical in a fraction of the time.
The bottleneck wasn't design or engineering skill, it was actually the friction between them. So I built two tools to remove it. Prototyping Workbench moves designers and PMs out of Figma onto a surface developers actually work in: coded prototypes made of real design system components, following production code conventions. IDS Inspector automates design QA on live pages and hands fixes directly to AI coding agents.
The manufacturing vertical shipped in three months.
Scope of Work
Tech Stack
How i navigated this project
02
Research was production code archaeology
I read 7 production repos and the design system source to learn how the product is actually built : 73 components, 557 tokens, 5 canonical structural patterns. The tools know the system because I extracted the system.
04
Adoption over mandate
Both tools spread through demos, Slack, and word of mouth and by proving themselves inside the manufacturing sprint, then crossing to other teams with zero enforcement.
01
The Bet
The mandate was a ship date, not a tooling roadmap. I spent the early weeks building tools instead of absorbing the friction, a real risk on a three-month timeline, wagering that every week after would move faster. It paid back before the deadline did.
03
Sequence mattered
Workbench first, to collapse design-to-development translation while the vertical was being designed. Inspector second, to close the QA loop once code was flowing. Build velocity, then guard it.
Project details
The Problems
Every feature moves through the same loop: design intent → build → ship → verify against spec → back to design. Ours was paying a tax at both ends and a three-month vertical had no room for either.
Problem 01
The translation tax: where design becomes code
Design lived in Figma, the product lived in code. Every conversation between them was a translation exercise. AI prototyping promised a shortcut but outputs looked like concept art. The AI didn't know our design system, our shell, or our patterns existed. Every iteration reverted to Figma. The round trip made AI prototyping cost more than it saved. Developers rebuilt from static mockups, re-deciding details the design had already decided.
Problem 02
The drift tax: Production drifting from spec
Project details
The Opportunity
One belief shaped every opportunity, 'don't ask people or AI to remember the rules'. Build the environment, so following the rules is the easiest possible action. Constraints, encoded into tooling, do the work that documentation and discipline can't.
Opportunity 01
Production drift → Live inspection tool
AI tools weren't generating bad prototypes because they couldn't write code. They were generating bad prototypes because they didn't know the system existed. The fix wasn't a smarter model it was a smaller world, an environment where the design system is the only material available.
Opportunity 02
Production drift → Live inspection tool
What if any designer could point at any element on a live page and get a verdict compliant or not, and the canonical fix instantly? And what if the finding didn't stop at a human-readable report, but became a ready-to-run prompt for an AI coding agent?
Break down big goals into smaller steps and keep momentum with clear priorities.
Project details
The Goal
Define one source of truth to solve for the systemic gaps. Extract how the product is actually built-every component, every token, every canonical pattern once, and power the whole toolchain from it. The prototype environment and the QA tool agree, because they read from the same system.
Expected Outcomes
The Toolchain
Project Details
The Process & Hard Design Calls
Some of the major inflection points throughout the project
01
The strategic call: grind through the friction, or build the tool that removes it?
The mandate was a ship date; nobody asked for infrastructure. The expected path was absorbing the friction- more meetings, more redlines, more translation. I bet my personal time on tooling instead, wagering every week after would move faster. And I built it as org infrastructure, not personal scripts because if my team was paying this tax, every vertical team was. Individual hacks don't compound. Shared tooling does.
02
Mirror the product, don't rebuild it
03
Design for the agent handoff, not just the human
04
Verdicts, not data dumps
Partner Testimonials
"I would say if I was going through a session it's saving me at least 50% of the time it would take to do this manually, and in some cases that's more like 75% time savings."
Adam Beasely
Senior Product Designer, Intuit
"Manas built and shipped IDS Inspector independently, a tool the design team is already using in daily QA. Impactfully using prototype workbench to drive alignment in triad and leadership discussions for Landed Costs and Serial/Lot Tracking."
Nikita Gill
Design Manager, Intuit
