Aaqil Jamal

Design System Lead — owned the architecture, built and maintained components, established governance, and drove adoption across the team. Evolved the system over 5 years at Zetwerk.

Our Figma files were painfully slow. Loading a single page took 2-5 minutes. Prototypes would hang. Designers were frustrated, and productivity was tanking.

We were migrating from Sketch and needed to rebuild our component library in Figma — but doing it the "right way" meant understanding why things were breaking in the first place.

My manager suggested I study Moja UI, a well-regarded design system on the Figma community. They used a "master component" approach — creating base components for every possible state (border colors, helper text, base colors), then combining them into variants.

A single input field ended up with 20+ variants just to cover all combinations. Multiply that across a full component library, and you get massive files that choke Figma's browser-based memory.

A designer friend outside Zetwerk showed me a different approach: boolean-based components. Instead of creating exhaustive variants, I could build just 4 states (default, selected, error, disabled) and use boolean toggles to show/hide elements like icons, prefixes, and helper text. This dramatically reduced layer count while maintaining flexibility.

I proposed the boolean approach to my team, then to product leadership. We went all in.

• Architected the component structure using the boolean methodology
• Built and maintained 20+ components (buttons, inputs, checkboxes, modals, tables, page layouts)
• Established design governance — controlling when new components were created vs. reusing existing ones
• Reviewed components from other designers for consistency and performance
• Created a UI Library with page-level patterns (modals, forms, navigation)

We needed a system to prevent component sprawl. Before creating new components, designers had to check if existing ones could work. New component requests went through review. I maintained hygiene checks to ensure consistency.

The boolean approach worked great for designers, but developers struggled with it. Component names were more generic, and devs couldn't easily tell which state to reference. Some started building their own components instead of using ours.

We evolved toward better documentation and a token-based approach. I collaborated closely with developers to align naming conventions with how they think about UI. When we rolled out the timeline/audit history component using this collaborative approach, adoption improved significantly.

• Boolean-based component architecture reducing variant count by 80%+
• 20+ production components — atoms, molecules, organisms & page layouts
• Governance process with contribution guidelines, review workflows, and version control
• Token-based styling enabling theme-switching and white-labeling
• Developer-aligned naming conventions and comprehensive documentation

File performance transformed — load times went from 2-5 minutes to under 10 seconds. All 12 designers across 7-8 products adopted ZetUI. We created mini design systems for client-facing products. Governance processes, component hygiene, and cross-team collaboration became the norm.

• Start with tokens — define design tokens first, then build components on top of them
• Involve developers earlier — align naming conventions and mental models from day one
• Be ruthless about scope — we kept 10+ tag colors when we really only needed 3-4 system colors
• Balance booleans with variants — Figma now has bulk-update features, so a hybrid approach would work better

Lead Designer (90% ownership) — designed the shipment tracking system end-to-end, from information architecture to final UI.

Zetwerk's NAB business unit manufactures solar beams and piles for US customers. That means international shipping: products move from Indian factories to Indian ports, across the ocean to US ports, and finally to customer locations.

Before ZHIP, this was all tracked in Excel. Unknown delays were costing the business ~₹3 Cr annually in demurrage charges — fees charged when containers sit at ports longer than expected.

• Multiple legs per shipment — Bangalore → Chennai Port → US Port → Customer (3+ legs)
• Multiple loads per leg — 100 MT of material might need 5 trucks (20 MT each)
• Container-level tracking — each container can get stuck at ports for days or weeks
• Different tracking sources — GPS + Fastag for India, GPS or manual updates for international

How do you represent a shipment that has 3 legs, with 5 loads in the first leg, 2 containers in the second, and variable tracking sources — in a way that's both scannable at a glance AND detailed enough for operational decisions?

This wasn't a simple status tracker. I needed to design for hierarchy (Shipment → Legs → Loads → Containers), time tracking (expected vs actual dates), geographic context (map view), and mixed data sources (automated GPS pings + manual updates).

I structured the interface around the leg + load model:

• Shipment overview — high-level status with origin, destination, and expected delivery
• Load list panel — all containers/trucks with individual statuses
• Route timeline — each stop with expected vs actual dates
• Map view — geographic context showing current position

The hardest part was the initial setup — figuring out the layout and how users would create, track, and visualize complex shipments. This took multiple iterations.

• Worked closely with NAB logistics team to understand delivery types (FOB, DDP, CIF), shipping lines, container constraints
• Mapped the information hierarchy — shipments contain legs, legs contain loads, loads have status stages
• Tested different approaches to show leg/load relationships before landing on the split-panel view
• Designed for edge cases — containers stuck at ports, partial shipments, delays at customs

• Four shipment creation flows depending on context (with contract, without contract, from packing list, manual)
• Template-based status updates with standardized stages (Gate Out Empty, Gate In Full, Load, Departed, Arrival)
• Multi-mode tracking — GPS + Fastag for Indian land transport, manual fallback for international legs
• Customer Portal sync — updates auto-reflected for US customers without extra work
• Complete audit history of all updates, attachments, and status changes

90% adoption by NAB logistics team for tracking international shipments. Replaced fragmented Excel sheets with a single source of truth. US customers could track shipments in real-time via Customer Portal.

Higher management still used Excel for quick status glances, but the operational team — the logistics managers actually creating and tracking shipments — moved entirely to ZHIP.

• Invest in information architecture first — the leg/load hierarchy was the foundation everything else built on
• Domain complexity requires domain immersion — I couldn't design this without understanding shipping terminology and container logistics
• Design for the operational user — management wanted dashboards, but the real value was in helping logistics managers do their daily work
• Iteration on core structure > iteration on features — once the layout clicked, adding features was straightforward

Sole Designer & Research Lead — owned this project end-to-end: conducted all user research, created PRDs, designed user flows and wireframes, proposed feature roadmaps, and navigated 3 PM changes over the project's lifecycle.

Zetwerk's procurement process was fragmented. Different teams used different tools — Excel sheets, WhatsApp, emails, PDFs, and an expensive external tool called Procol for reverse auctions. Nothing talked to each other.

• Site managers sent requirements via email or WhatsApp
• Procurement teams manually tracked 100+ purchase requests per month
• Quote comparisons happened in Excel with 300+ quotes monthly
• Approvals were scattered across calls and emails
• No audit trail, no single source of truth

“I spend 50-60% of my time converting quantity metrics and getting agreed upon terms and conditions. I end up helping other BUs which takes up my time as well.”

Multiple BUs were paying lakhs monthly for Procol, an external reverse auction tool. Beyond cost — data lived outside Zetwerk's ecosystem, cross-system communication was manual, and we couldn't customize workflows. The opportunity: build ProcureZ as part of Zetwerk's product suite.

I spent 3-6 months conducting discovery research across all EPC business units: Water, Railway, T&D, Oil & Gas, and Sharp Tank. Each BU had its own procurement quirks, but I needed to find the common threads.

• Stakeholder interviews — 10-12 sessions across 3-4 personas per BU (site managers, procurement teams, engineering teams, approvers)
• Supplier interviews — understood the other side of the RFQ process
• Competitor analysis — deep dive into Procol's interface (even captured supplier-side screenshots)
• Process mapping — documented end-to-end procurement workflows for each BU

Three distinct user groups with different needs: PR creators (site managers), Procurement/RFQ teams, and Approvers. Unit of measure conversion was a massive time sink. Visibility was the core pain — teams couldn't see where requests were in the pipeline.

ProcureZ would be a single platform connecting all three user groups:

• PR Creation — Site managers submit purchase requisitions with standardized templates
• RFQ Management — Procurement team sends RFQs, tracks quotes, runs comparisons
• Reverse Auction — Built-in auction system replacing Procol
• NFA & Approvals — Streamlined sign-off workflow with full audit trail
• Complete research documentation, PRDs, user flows, wireframes, and feature prioritization matrix

The project went through 3 PM changes over 12+ months. Each transition meant re-alignment, re-scoping, and sometimes re-doing work. I became the thread of continuity.

ProcureZ shipped, but adoption was lower than hoped — around 10-15%. The business focus had shifted by launch, and the full scope (RFQ, NFA modules) was still in development pipeline. The PR creation module saw the most usage.

While the adoption numbers weren't what we aimed for, the research and groundwork I laid became foundational for future procurement initiatives at Zetwerk.

• Ship smaller, faster — a 12+ month timeline with shifting priorities is risky. Smaller releases would have built momentum
• Research is only valuable if acted upon — extensive documentation meant nothing when organizational changes diluted the impact
• Be the constant — through 3 PM changes, I maintained project continuity. That's a skill
• Constraints breed creativity — the LCP limitations forced simpler solutions, which sometimes was actually better

UX Foundation Lead + Production & QC Design Owner — established UX principles, device strategy, and accessibility guidelines. Owned the complete production lifecycle plus QC inspection flow on handheld devices.

Siemens Gamesa — one of the world's largest wind turbine manufacturers — was setting up a new manufacturing plant and needed a complete tech stack for tracking inventory, production, quality inspections, and dispatch.

3 months. That's all we had — including PM alignment, business sign-off, design, and development.

• Factory floor environment — users wearing gloves, headgear, working in noisy environments
• Handheld scanner devices — Zebra TC21 Android computers with built-in barcode scanners
• Serial number tracking — every item needed unique identification through its lifecycle
• BoM complexity — products made of multiple Sets, each containing dozens of components
• QC variations — large items need individual inspection; nuts & bolts need sample-based QC

Before diving into screens, I stepped back to establish the foundation. I researched factory management systems like Katana and AMFG, combined with ground reality from our PMs who visited the factory. The result was a comprehensive guidebook covering devices, accessibility, and UX principles.

Different tasks needed different devices:

• Display boards — at start/end of production lines for capacity and progress visibility
• Desktops — for production managers creating orders, managing picklists, tracking status
• Tablets — fixed at production line stations
• Zebra TC21 handhelds — Android computers with built-in scanners for QC, picking, and warehouse operations

Factory workers aren't sitting at desks. They're wearing gloves, safety headgear, working in noisy environments. The UI had to account for larger fonts, high contrast, large tap targets, and multilingual support.

I documented 9 UX principles: Simple & Clean UI, Reduce Navigation, Command Center dashboards, Action on the Go, Reduce Data Entry (scanning over typing), Clear Call-outs, Smart Recommendations, Audio Alerts for critical errors, and Real-World Patterns that mirror offline workflows.

I designed the complete production lifecycle — Production Order creation, BoM validation with comprehensive error handling, Edit Picklist with item/Set swap systems (V4 — four iterations to get right), BoM Reversal for scrapped products, and QC Inspection flows for handheld devices.

The QC inspection was the most complex piece. Not everything can be inspected the same way:

• Serial + Individual — one item, one serial, full inspection
• Group Serial + Sample — box of items, sample-based QC
• Group Serial + Individual — multiple locations, track pass/fail per location
• Manual Approval — QC optional, auto-passes but can capture docs
• Partial Pass — 75 of 100 items pass, 25 fail

• Production Order system — full lifecycle from Draft → Created → Released → In Production → Completely Produced → Closed
• BoM validation with detailed error system showing what's wrong, why, and how to fix it
• Picklist swap system — replace individual items or entire Sets with quantity validation and preview
• BoM Reversal flow — reason capture, inventory status decisions, location assignment, full audit trail
• QC Inspection for 5 different inspection types on Zebra TC21 handhelds
• Printable Pick List with checkboxes, comments column, and contact info for warehouse pickers

ZPS launched on time. Factory workers at Siemens Gamesa started using the system for daily operations. Enhancements came after launch based on real user feedback.

With 3 designers working in parallel under extreme time pressure, our designs started to drift. Each designer added their own flavor — noticeable inconsistencies in spacing, component usage, and interaction patterns. Principles alone weren't enough.

This taught me a direct lesson. When we built ZINTO (our next inventory product), I set up a mini design system with specific component patterns before parallel design work began. The result: much tighter design consistency.

• Edge cases ARE the design — error handling, swap flows, reversal — these are where users spend real time
• Context changes everything — handheld scanner UI is fundamentally different from desktop
• Foundation work scales — the upfront investment in principles enabled 3 designers to work in parallel
• Principles need patterns — abstract guidelines aren't enough; concrete components prevent drift

Solo founder — product strategy, UX design, full-stack development, WhatsApp bot architecture, API integration (Meta, Razorpay, Brevo), database design, PDF engineering, infrastructure, design system, brand identity, and go-to-market.

India has over 15 million freelancers — designers, developers, writers, consultants — and most run their entire business through WhatsApp. Yet invoicing still means spreadsheets, generic apps built for larger businesses, or screenshots and mental math.

Freelancers lose an estimated 10–15% of their revenue to late or forgotten payments, spend hours on admin work, and avoid awkward payment reminders — all because no tool meets them where they already work.

Twilio → Meta Cloud API: native interactive buttons + 1,000 free conversations/month. This single decision improved both UX and unit economics.

Invoice creation IS the onboarding. The original flow was 10–15 interactions before anything useful. Restructured so creating the first invoice is the onboarding — collect only name and email upfront, gather everything else at the point of need. Identified as the biggest launch risk through pre-mortem analysis.

AI natural language invoicing ("bill Rahul 40K for brand redesign") gated behind Pro to protect margins. Free-tier gets guided step-by-step flow. Keeps ~90% gross margins intact.

Database redesigned from flat invoices table to documents + extensions + line items — turning an invoice tool into a future document platform (quotations, contracts, proposals).

Discovered that storing WhatsApp conversation state in memory broke during server redeployments, losing users mid-flow. Migrated to database-backed state persistence with atomic operations. A painful lesson that shaped every architectural decision after.

• Production-ready — core product built, deployed, and functional
• Live infrastructure — riffit.in (marketing), app.riffit.in (dashboard), WhatsApp bot operational
• Razorpay integration complete — Pro plan with full subscription lifecycle
• Meta Business verified — Udyam MSME registration, WhatsApp Business API approved
• Brand migration complete — full rename from BillPe → Riffit across everything
• Monitoring live — Sentry error tracking, Brevo transactional emails
• Early Access: early-access businesses invoice on it today, on the free plan or Pro (₹249/mo, ₹199/mo billed yearly), and every new account starts with a 14-day Pro trial

Frontend

Next.js, TypeScript, Tailwind CSS v4

Backend

Next.js API Routes (Vercel Serverless)

Database

Supabase (PostgreSQL + RLS)

WhatsApp

Meta Cloud API

Payments

Razorpay Subscriptions

Email

Brevo (transactional + marketing)

PDF

@react-pdf/renderer

Design System

RiffUI (custom neobrutalism)

Monitoring

Sentry

• riffit.in

Product and design lead, as part of a small team: product direction and specs, the brand story and design language, the @tovak-os design system, most of the web app's front end since August, the marketing site, and the sales kit and demos.

Indian factories doing ₹5–50 crore a year run on WhatsApp groups, paper registers and Tally. Orders arrive as chats and voice notes, production status takes a phone call, and the same order is entered three times: on WhatsApp, in a register or Excel, then in Tally. Tally keeps the books but never sees the floor, and a full ERP asks a floor team that lives on WhatsApp to learn a desktop app.

Three groups decide whether software sticks. The owner wants to know what's late and who owes him. His chartered accountant can veto any tool and asks one question: does it export clean data to Tally? And the supervisors and storekeepers will never open a web app at all.

The records already exist. The storekeeper writes everything down. What breaks is the re-entry, and the month-end gap between the register, the stock and the books.

Replace nothing. WhatsApp stays the interface and Tally stays the books; Tovak is the operations layer between them. That made a Tally export a day-one requirement instead of a later integration, because without it the accountant says no.

The model reads, our code decides. A WhatsApp message goes to a language model only to work out what was asked and what was mentioned. Matching "Sharma" to one real client, checking the stock and writing the record all go through the same permission-checked API as the web app, with a one-tap confirm on every write. Deletes and voids aren't allowed over WhatsApp at all. The model can point at words; only the database can name a record.

The floor never sees money. What you see follows your role: the floor works with jobs, stages and quantities, while prices, receivables and payments stay with the office. When I rebuilt the owner's dashboard, its money band became something only the roles allowed to see finance ever render.

Severity first, money second. The dashboard ranks what's wrong across invoices, jobs, dispatches, quality and stock. Sorting by rupees alone would put a large invoice above a quality issue that has stopped the line, so critical always outranks warning and money only orders rows within a tier. No kind gets more than five rows, so forty overdue invoices can't push everything else off the screen.

I built the design system as its own product: a separate repo of versioned packages (tokens, components, brand assets) that the app installs, with a rule against raw colours and one-off values in product code. Screens are assembled from it rather than drawn one at a time, which is how the app's list pages moved onto one shared shell in under a week.

One press of Escape closed two layers and threw away a filter nobody had applied yet. Two copies of the same Radix package had installed side by side, each keeping its own stack of open overlays, so a popover and the panel it sat in both believed they were on top. Pinning one copy fixed the app; moving every Radix package in the design system to one generation fixed the cause.

• Live: tovak.in, the web app at app.tovak.in, and the WhatsApp bot, verified in English and Hinglish
• Pilot phase: product demos with manufacturers and hands-on onboarding
• The order-to-cash chain runs end to end: quotation, sales order, work order with production stages and a printable job card, dispatch, GST tax invoice, receivable, payment
• GST invoice PDFs, e-way bills, credit and debit notes, and an XML export for Tally
• Quotations on a four-step wizard whose preview is drawn by the real PDF renderer, plus a terms library; a sent quote keeps its own copy of its terms, so editing a template can't change it
• The @tovak-os design system: tokens, 89 React components built on shadcn and Radix, brand assets and a studio for on-brand images and PDFs, published as versioned packages with Storybook
• A UX audit of the whole app, seven sweeps through every screen, worked through in batches, worst first. The worst find: a failed request made a list of 73 work orders look like an empty factory, "No work orders yet"
• Marketing site: a Next.js static site with a scroll-scrubbed fly-through of a factory floor, which drops to lighter or static frames on slow phones and under reduced motion

Web app

React 19, Vite, TanStack Router + Query, Tailwind CSS v4

API

NestJS modular monolith, Drizzle ORM, Zod

Database

PostgreSQL on Neon

WhatsApp

Meta WhatsApp Cloud API (direct, no BSP), WhatsApp Flows

AI

GPT-5 mini behind a swappable provider interface

Design System

@tovak-os tokens, UI (shadcn/Radix), brand assets, Storybook

Documents

PDFKit, pdfcpu, Tally XML export

Marketing site

Next.js static export, GSAP ScrollTrigger, Web Worker frame decoding

Hosting & ops

Render, Resend (email), Sentry, PostHog

• tovak.in

Everything — product strategy, UX/UI design, frontend development (vanilla JS, then React), data engineering, custom tooling (Segment Editor), audio engineering, the native Android build, cross-platform QA, and deployment.

Existing Quran learning apps don't support Waqf-based segmented learning — the traditional method where verses are broken at natural pause points for easier memorization. A family member needed this tool. Nothing on the market offered it.

Learners were forced to memorize entire verses at once, which is overwhelming for beginners and inconsistent with how Quran is traditionally taught through oral recitation.

Worse — the Waqf-segmented data didn't exist anywhere online. The product couldn't be built without first creating the data from scratch.

Vanilla JS with zero dependencies — every interaction, state change, and animation was hand-built. This ensured the app loads fast and works reliably across all devices including older phones common in Muslim-majority regions.

Built a custom Segment Editor with visual audio waveforms for marking precise audio boundaries — a full bespoke audio annotation tool. A "tool to build the tool" decision that made the entire data pipeline sustainable.

Word-level highlighting over line-level, because it mirrors the traditional "follow along" method and feels like having a teacher point at each word. The first version spaced each word's timing evenly across its verse, and the highlight drifted from the recitation; the rebuild imports real per-word alignments (cpfair/quran-align, CC-BY 4.0) for 6,227 of the 6,236 verses.

PWA over native app for the first version — instant access without app store friction, critical for the target audience. The rebuild went the other way: v2 is a React app shipped natively through Capacitor, so saved surahs play with the network off and the recitation keeps going on the lock screen.

• v1 is live on GitHub Pages: the vanilla JS web app, with segment-based navigation, word-by-word highlighting and resume
• v2, a React rebuild, runs natively on Android: onboarding, duas by theme, a player that follows you across the app, and surahs saved for offline that play with the network off, verified on a real phone
• The data underneath was rebuilt too: all 2,640 pause-marked verses segmented, real word timings for 6,227 of 6,236 verses, and 56 corrupted words restored
• Next: the Play Store, after a review of the recitation's licensing and the Qur'an text's accuracy

The fact that a custom audio annotation tool had to be built just to make the product possible shows the depth of this project. It's not a designer who made mockups — it's end-to-end product creation from a gap that had no existing solution.

Frontend

Vanilla JavaScript, CSS, HTML (v1)

App (v2)

React, TypeScript, Capacitor (Android)

Architecture

PWA (Service Workers, offline caching)

APIs

Quran.com API, AlQuran.cloud API

Audio

Web Audio API, Media Session API

Tooling

Custom Node.js Segment Editor

Hosting

GitHub Pages

Data

Custom JSON (Waqf segments + word timestamps), cpfair/quran-align alignments

• Open Sabeel

Solo on everything — product strategy, UX/UI design, Chrome extension development (MV3), backend (Vercel serverless), API integration (Jira, Gmail, GA4), security engineering, email marketing system, analytics, and Chrome Web Store distribution.

Bug reporting takes 5+ minutes per bug — screenshot, save, open Jira, create ticket, upload, paste context. Focus is broken, context is lost. By the time you've switched tabs three times, you've forgotten the exact state you were trying to report.

Built the infrastructure around the product, not just the product itself. Once real users installed, I needed email automation, campaign tools, health monitoring, and an unsubscribe flow — systems most side projects skip entirely.

AES-256-GCM encryption for credential storage. Users save Jira API tokens, so plain chrome.storage wasn't an option. Built a full encryption layer with separate key storage.

Jira field validation with live API calls on blur, not on input. Early versions validated on every keystroke which was annoying. On-blur validation actually calls Jira's API to verify project keys and assignees exist — preventing bad submissions without frustrating users.

After seeing a 78% drop-off between install and first open, explored several approaches. Chose badge notifications ("Setup") on the extension icon — draws attention without hijacking the browser. Non-intrusive activation that respects the user.

• Live on the Chrome Web Store, with 200+ users at its peak
• Grown into Snap to Jira, ClickUp & More: one extension that files to Jira, ClickUp or Linear, records 60-second screen videos, and (opt-in, per site) attaches steps to reproduce, console errors and failed network requests
• Active user base with automated onboarding emails
• Full production infrastructure — GA4 tracking, Discord alerts, UptimeRobot monitoring
• Admin dashboard for HTML email campaigns with user targeting
• Actively iterating — analytics showed only 2/9 tracked installs opened the popup, leading to onboarding improvements

This was my first-ever coded product. The gap between "I made a thing" and "I shipped and maintain a thing strangers depend on" is exactly what this project demonstrates.

Extension

JavaScript, Chrome MV3, Canvas API, Web Crypto

Backend

Vercel Serverless, Node.js

APIs

Jira REST, Gmail OAuth 2.0, GA4 Measurement Protocol

Security

AES-256-GCM, Content Security Policy

Monitoring

Discord webhooks, UptimeRobot

Email

Gmail API, HTML templates

Analytics

Google Analytics 4

• Chrome Web Store

Product strategy, plugin architecture, data engineering (Excel + openpyxl), newsletter intelligence pipeline, HTML dashboard visualization, and generalization from internal tool to distributable product (Cintel).

Competitive intelligence in the behavioral health AI scribe market was entirely manual — individually checking seven competitors' blogs, pricing pages, Reddit threads, newsletters, G2 reviews, and social media every day. Critical competitive moves could go unnoticed for weeks.

• Claude Cowork plugin with 5 slash commands (/setup, /daily, /newsletters, /weekly, /status)
• Structured Excel reports with threat-classified intelligence feeds (HIGH/MEDIUM/LOW)
• Newsletter scanning pipeline processing 17+ competitor emails across multiple accounts
• HTML dashboard with threat heatmaps, competitor activity charts, and timeline views
• Date verification system to filter stale web results from threat assessments
• Generalized version (Cintel) — configurable plugin any business can install with interactive setup wizard

• Excel as data store, HTML as read layer — zero infrastructure, immediately shareable with teams
• Plugin architecture over loose scripts — single-command workflows (/daily) instead of copy-pasting prompts
• Generalized from SignalStack to Cintel — externalized all hardcoded data into a config file with setup wizard
• Newsletter scanning as primary intelligence source — higher-quality, more intentional signals than web monitoring
• Date verification as data quality gate — prevented logging stale content that skewed threat assessments

Live and operational. SignalStack runs daily scans for Supanote. First scan immediately surfaced actionable intel (JotPsych's JotAudit launch as a HIGH threat). Cintel packaged with MIT license, ready for distribution. Runs on Claude Max with zero additional infrastructure costs.

Claude Cowork Plugin Architecture · Python (openpyxl) · Web Search · Gmail MCP · Xpoz MCP · Firecrawl MCP

Live. Generalized version ready for distribution.

Workflow architecture, design system token extraction (shadcn/ui), MCP integration & debugging, component design (7-state progress stepper), technical writing (setup guide + LinkedIn post).

At Supanote, everyone — founder, PM, marketer, designer — uses AI to build prototypes. Every output looked different. And once created, there was no way to push code back to Figma for design refinement. Two disconnected sources of truth.

• End-to-end pipeline: Claude Chat (ideation) → Claude Code (production React) → localhost → Figma (editable frames)
• Extracted design tokens from shadcn/ui Figma source file into reusable reference
• Configured CLAUDE.md as design system source of truth — every AI session stays on-system
• Connected Figma MCP server + discovered the plugin vs MCP server distinction (undocumented)
• Built a 7-state AI Progress Stepper component with elapsed timer and staggered animations
• Documented the entire process as a replicable guide other designers can follow

• Plugin over raw MCP — discovered that basic setup is read-only; generate_figma_design needs the separate plugin. No existing tutorial covered this.
• CLAUDE.md as design system source of truth — design tokens baked in so every session auto-generates on-system UI
• Chat-first iteration, code-second build — separates creative divergence from technical convergence
• Cross-account Figma sharing — shared work files to personal account for MCP access without re-auth friction
• Published within 48 hours of Figma's feature announcement — first-mover documentation

Working end-to-end pipeline, actively used for Supanote product design. Progress stepper component successfully built, previewed at localhost, and captured as editable Figma frames. The setup guide is published on Bootcamp (May 2026): "The Complete Guide to Setting Up Claude Code to Figma from Someone Who Actually Did It".

Claude Code (Opus 4.6) · Next.js 16 · shadcn/ui · Figma MCP Server · Figma Plugin · Tailwind v4 · TypeScript

Active. Used daily for Supanote product design.