At a glance
- Role. Lead Design Technologist + AI Systems at mixshift.ai (opens in a new tab), embedded with the team since October 2024.
- Owned. Product design, the frontend systems, the design system, the AI knowledge tools, and the automation underneath the team.
- Built. The design system, Report Center 2.0, the marketing site, a retrieval-backed knowledge base with its own chat agent, and the org brain.
- Operating proof. 175 components, a 55-article knowledge base, twenty-six scheduled automations, all in MixShift's own repositories.
- What it shows. Product judgment, production engineering, AI systems, and infrastructure a team keeps running.
Jump to: Design system · Report Center 2.0 · Marketing site · Knowledge base · Org brain · Decisions · Evidence
This is an active engagement, so I use repository evidence and operating scale rather than confidential business metrics. Everything below is backed by a commit, a file or a spec in MixShift's own repositories.
The problem
A small team, a data-heavy product with a lot of surface area, and nobody whose job it was to make the interface coherent, make the marketing site exist, or make the company's own knowledge findable. Left alone, each of those gets filled ad hoc: one screen at a time, one document at a time, one answer repeated in one more chat.
The role
Embedded ownership. Their repositories, their standups, their review queue. Design is my domain by name, and I am also the frontend lead and the named design co-owner of the Report Center 2.0 specification alongside the product owner.
The operating agreement. Stylesheets, Tailwind config and component directories route to me for review, and the production-readiness plan resolves a screen's design before it is built. That was negotiated with product and engineering, not imposed, and it is the difference between a designer on a team and design as a function of the codebase. Around it sits the enablement layer nobody lists on a job description: onboarding teammates to Git, Vercel and agent tooling, environments and secrets across three platforms, the vault architecture the company converged onto, and the standing SEO review every piece of content clears before it links out.
Design system
The problem. A component catalog split across apps, with no shared source and no way to stop drift.
What I changed. Co-authored the system and own its design half: 175 components and 109 stories in Storybook, plus 13 foundations pages I wrote, ported in lettered groups over three weeks, each group its own pull request. I selected the core stack, including a paid Highcharts license rather than a watermark, and wrote a theme decorator keeping the Tailwind and design-token halves of dark mode in step. It carries an MCP server, so agents query components instead of guessing.
What became possible. Drift stopped being a review problem and became a build problem:
- A CSS token-validity test fails the build when a component references a token that does not exist. It came out of one review where five separate findings traced to the same bug class, and nothing else in the toolchain could catch it: typecheck does not parse CSS strings, lint does not validate custom properties, jsdom returns the literal variable, and the accessibility checker does not flag an unset background.
- Accessibility violations fail CI, not advisory.
- A Monday-morning design health check walks the codebase for loading, error and empty states and posts a scorecard to the team.
- A designer QA playbook across five apps and roughly eighty pages, at the same two viewports as the automated screenshot harness, so a human finding and a machine finding line up one to one.
Six rounds of review on a single pull request are in the log. I work the review loop, not around it.
Report Center 2.0
The problem. The product's hardest surface had real defects a customer hit daily, and no single document said what it was supposed to do.
What I changed. A UX audit naming about twenty concrete defects, a features inventory of the existing monorepo, an eighty-five-story catalog, and then the design itself delivered as a running React application rather than mockups.
What became possible. The prototype was reconciled into the specification across a dozen changelog entries and superseded it, so the argument about what to build happened in something people could click.
Read the Report Center 2.0 case study →
Marketing site
The problem. No marketing site, and a brand that had never been set down.
What I changed. A brand and design-system overhaul first, then the site on top of it from the first commit: 162 components across 31 routes. Six rounds of audit, one of which removed fabricated content and unverified statistics the company could not support.
What became possible. A site that stays correct under real traffic, which is the half nobody photographs: consent-gated analytics, four tiers of anti-spam added as attackers adapted, and a domain migration scoped to the host so a partner-portal listing survived it mid-review.
Read the MixShift Marketing case study →
Knowledge base
The problem. The company's own knowledge lived in people, so the same answer was retyped in one more chat.
What I changed. A 55-article corpus and a retrieval-backed chat agent, about 3,760 lines of TypeScript; I authored all 20 source files. A hand-written BM25 ranker rather than an embedding call, four layers of defense on the chat route, and an eval whose trap questions make a confident answer to an uncovered question a failing run.
What became possible. One pipeline now serves three consumers, a human reading a page, a model answering a question, and a crawler indexing the corpus. It is public, so unlike everything else on this page you can check it yourself.
Read the Knowledge Base case study →
Org brain
The problem. Decisions lived in meetings, and meetings evaporate.
What I changed. An ingestion that writes meeting notes and atomic to-dos into per-project folders, one file per owner per action item, with deterministic ids so a rerun on the same dump is a no-op. It infers project tags, classifies each item and detects blockers. Beside it: an analytics sync, a daily briefing, and a gap finder that inspects my own schedules and surfaces what silently stopped.
What became possible. The company's memory became queryable, and twenty-six scheduled automations sit on top of it running the content operation end to end. The governance is written down: humans own version control, agents only write files.
Open the operations layer → shows all twenty-six on a working day, and the rules every one of them was written under.
The decisions worth naming
- Design as a function of the codebase, not an opinion. Review routing, design-resolved work, a scheduled audit and a build gate form a closed loop. I wired the checks into the merge path, then automated the parts a human should not have to do.
- Design in code, not in pictures. The Report Center prototype was a running application, and it became the spec.
- Delete claims you cannot support. Including the company's own marketing copy.
Repository evidence
What the version history shows:
- Marketing site. Origin and top author: 163 commits from March 2026, 1,142 files touched.
- Design system. 444 unique files created, the most of any author, across 146 commits touching the library. A shared library; the design half is mine.
- Knowledge base. Every one of its 20 source files created by me, on a 55-article corpus.
- Org brain and automation. Sole author of the vault and its ingestion, sync and briefing scripts, and I established the company's first automation registry entries.
And what it is running:
- The design system in use across five apps and roughly eighty pages.
- CI gates on token validity and accessibility running on every relevant change.
- 55 articles feeding three consumer surfaces: the page, the chat agent and the crawler.
- 26 scheduled jobs running inside the company's own environment.
Why this matters
Most companies have someone who cares about the interface. What MixShift has is a review agreement, a gate that fails the build, a Monday audit, and a specification that resolves a screen's design before it is built. That is what design engineering looks like when it is a function rather than a person, and it is the same discipline behind the design systems I built at Disney and Apple.
The knowledge base and the automation estate are the other half of the argument: a full retrieval product and a twenty-six job operation, with the gates, seams and incident discipline of production software. The design-systems instinct transfers to AI-native tooling. MixShift is where I proved it inside a company's stack.