Services

I build the systems behind better products.

I help product teams build consistent interfaces, organize their knowledge, and put AI into production. Start with a focused engagement or bring me a larger problem.

Discuss a custom system

Five services

Two focused services with a fixed scope, and three systems scoped to the problem you actually have.

01 ·
Audit

Design System Drift Audit

Available now · Fixed scopeBest forYour product no longer matches your design system.Find the gap between your documented design system and the interface your customers actually use.See the audit

02 ·
Motion

Product Motion System

Available now · Fixed scopeBest forYou need to show what your product does.Product animation that comes out of your design system, not around it.See the motion system

03 ·
Design

Design System Build & Operations

Custom scopeBest forYou need to build a system, or get teams using one consistently.Turn your design system from a collection of components into a maintained organizational capability.See this system

04 ·
Operate

Team Knowledge System

Custom scopeBest forDecisions and context disappear into documents and chat.Create an operating system for how your organization captures knowledge, makes decisions, and moves work forward.See this system

05 ·
Build

AI Delivery System

Custom scopeBest forYour team uses AI, but quality and workflows vary.Move from individuals experimenting with AI to a repeatable and controlled product-delivery system.See this system

How the five services relate

How the five services relate. Diagram described in text.

Stages:

  1. Design System Drift Audit. A focused diagnostic of one repository. Marked: Fixed scope.
  2. Design System Build & Operations. Governs interface quality and consistency. Marked: Custom scope.
  3. Team Knowledge System. Governs information, decisions, and coordination. Marked: Custom scope.
  4. Your product organization. The team, the product, and how it ships.
  5. AI Delivery System. Governs how work moves from intent to production. Marked: Custom scope.
  6. Product delivery. Quality, memory, and flow held together.
  7. Product Motion System. Launch and feature animation, built from your design system. Marked: Fixed scope.

Connections:

  • Design System Drift Audit leads to Design System Build & Operations, findings can inform a larger engagement (optional or feedback path)
  • Design System Build & Operations leads to Your product organization
  • Team Knowledge System leads to Your product organization
  • AI Delivery System leads to Your product organization
  • Your product organization leads to Product delivery
  • Product delivery leads to Product Motion System, what ships, shown on brand (optional or feedback path)
Five independent services that can also work together as an operating system for product delivery. The audit is a focused diagnostic, the motion system shows what ships in your own brand, and the other three create or improve organizational systems. None of them has to be bought as a bundle.

01 · Available now · Fixed scope

Design System Drift Audit

Find the gap between your documented design system and the interface your customers actually use.

I compare the implemented product against approved components, tokens, and patterns to identify visual, structural, and component-level drift.

ProofThe engine is open source and was tested against three unrelated public codebases, with every run published. Read the Zengin field tests

Delivery
Two working days
Scope
One repo, one system
Starts with
A free fit check
Availability
One per month
Discuss a custom system
Sample findingsfrom the public umami field test
  • unknown-propMobileNav.tsx:52flex-direction="column"Not a prop and not a DOM attribute. Reaches the DOM and does nothing.no fix
  • token-referenceHeatmap.module.css:77--border-baseReferences a token that is defined nowhere.no fix
  • component-substitutionSortableLabel.tsx:44<button> styled as ButtonA raw element rebuilt to look like a system component.nearest
  • color-literalHeatmap.module.css:15#d1d5dbHand-picked grey where the system ships a semantic token.nearest
  • spacing-literalTopNav.tsx:55margin: '0 6px'Off the spacing scale, so it will not follow scale changes.nearest

Every finding carries its file, the value found, a fix where one is honest, and how sure the engine is of it.

What I do

  • Compare production interfaces with approved design-system definitions
  • Identify incorrect components, tokens, variants, and implementation patterns
  • Distinguish genuine violations from legitimate product exceptions
  • Classify findings by severity, confidence, and remediation effort
  • Identify recurring issues that should be resolved at the system level
  • Create a prioritized path from findings to implementation

What you receive

  • Classified findings report
  • Prioritized remediation plan
  • Evidence connected to affected files, components, or screens
  • Recommended system-level fixes
  • Design and engineering walkthrough
  • Seven days of follow-up on the findings and remediation plan

Outcome

Your team understands where the product has drifted, what matters most, and what to fix first.

A focused, fixed-scope engagement for one repository and one design system.

Inside the audit

Automation creates the evidence. Judgment decides what it means.

From design-system definition to verified implementation

From design-system definition to verified implementation. Diagram described in text.

Stages:

  1. Approved definitions. Design tokens, Figma variables, Code components, Documented patterns.
  2. Production implementation. Screens, Components, Styles, Variants, Props and class names.
  3. Automated detection. Token mismatches, Component substitutions, Unsupported variants, Repeated one-off patterns, Undeclared props. Marked: Automated.
  4. Human classification. Confirmed drift, Legitimate exception, False positive, System-level issue, Product-specific issue. Marked: Human decision.
  5. Prioritized remediation. Fix immediately, Resolve at the system level, Document as an exception, Monitor over time.
  6. Fixes and verification. After the audit: your team, or a follow-on engagement; definition gaps go back to the system.

Connections:

  • Approved definitions leads to Automated detection, intent
  • Production implementation leads to Automated detection, as built
  • Automated detection leads to Human classification, evidence
  • Human classification leads to Prioritized remediation, what it means
  • Prioritized remediation leads to Fixes and verification (optional or feedback path)
  • Fixes and verification leads to Approved definitions (optional or feedback path)
The audit connects documented intent, production evidence, human judgment, and prioritized action. It ends at the plan: fixing and verifying are your team's work, or a follow-on engagement.

Before you commit

A free fit check tells you whether the audit works on your repository.

Thirty minutes, using the adapters that already exist. It answers one question, eligible or not, and reports the raw count from a first run. That count is an estimate of volume, not a set of validated findings. It does not include custom adapter work, deriving your definitions, classifying anything, or debugging a build that does not run. If the existing tooling cannot evaluate your repository in that window, I will tell you it needs paid scoping rather than quietly absorb it.

How the audit runsTwo working days after access and rule mapping, in five steps
Step 1

Fit check

Free, thirty minutes, existing adapters only. Eligible or not, and the raw count from a first run.

Step 2

Access and rule mapping

Prework, before the clock. Repository access, a clean build, and the rules derived from your own system.

Step 3

Audit and classification

Day one. Automated detection runs, novel cases get investigated, and up to 150 validated findings are read and classified by hand.

Step 4

Report and walkthrough

Day two. The classified findings report, the prioritized remediation plan, and a design and engineering walkthrough.

Step 5

Follow-up

Seven days. Questions on specific findings, and clarification of the plan as your team starts on it.

Technical scopeRequirements, included volume, exclusions, support

What the tooling needs

  • React and TypeScript with CSS. Tailwind v3 or v4 supported.
  • A design-system source it can read: a design-token file plus a components manifest, a shadcn-derived project, or an installed package that ships CSS variables and type declarations.
  • A repository that installs and builds from a clean checkout.
  • Read access to one repository, with any security review completed before the clock starts.

Included volume, and what happens past it

  • Up to 150 validated findings are classified by hand and included.
  • Past that, the overflow is prioritized and delivered unclassified. The fee and the delivery window do not change.
  • The free fit check reports the raw, unclassified count from a first run, so you know before you book whether you are likely to pass 150.

Not included

  • Building or migrating a design system
  • Fixing the findings on your behalf
  • Installing enforcement tooling or gates, which is design system build and operations work
  • Rolling this out across an organisation
  • More than one repository and one design system
  • Drift outside the engine's rule kinds, including behavioural, architectural and most accessibility drift

After handoff

  • Seven days for questions on specific findings and clarification of the remediation plan.
  • Not new analysis, more repositories, or remediation of the findings themselves.

02 · Available now · Fixed scope

Product Motion System

Product animation that comes out of your design system, not around it.

I direct and build launch and feature animations from your own design system, then hand your team the setup to keep making them. Every piece stays on brand because it comes from the same tokens, type and components as your product. I build them with Claude and review every one frame by frame.

ProofEvery card thumbnail on this page, and 52 pieces in two brands, were made with the same skills. See the free Motion Kit

Delivery
Ten working days
Scope
One brand, four pieces
Starts with
A free thirty-minute call
Formats
MP4, GIF, WebM, stills
Scope and boundariesLength, formats, revisions, exclusions
  • Each piece runs 6 to 15 seconds and loops cleanly
  • Two aspect ratios of your choice from 16:9, 1:1, 4:5 and 9:16, for every piece, in light and dark
  • Two review rounds: one on the still frames before anything moves, one on the motion
  • One brand and one product, from your existing design system
  • You keep the editable source of every piece, the brand file and the installed skills
  • To make the next piece yourselves: your own paid Claude plan with Claude Code, plus Node and ffmpeg for video exports. No ongoing subscription to my service is required
  • Not included: live-action video, voiceover, music, or building the design system itself

  • Container expand

  • Button to done

  • Chart morph

These, and the thumbnails on the five service cards above, were made with the skills in the free Motion Kit, from my own brand file. Sample data.

What I do

  • Build the brand file from your repository, Figma variables or live site
  • Choose with you the moments worth animating: the launch, the first run, the feature that sells
  • Agree the still frames with you before anything moves
  • Make each piece from the brand file, so color, type and timing come from your system
  • Check every piece frame by frame, in light and dark
  • Set the skills up in your repository and make one piece with your team

What you receive

  • A brand file built from your design system
  • Four pieces: one launch hero and three feature loops
  • The editable source of every piece, yours to keep and change
  • Exports for your site and channels: MP4, GIF, WebM and poster stills
  • Every piece in light and dark
  • The motion skills installed in your repository, set up for your brand
  • A working session so your team can make the next piece

Outcome

You launch with motion that looks like your product, and your team can make the next piece without starting over.

A focused, fixed-scope engagement for one brand and one product.

Try the free Motion Kit

03 · Custom engagement

Design System Build & Operations

Turn your design system from a collection of components into a maintained organizational capability.

I build and improve design systems, from tokens and production components to the contribution, release, and adoption practices that keep them useful.

ProofI build and run a 175-component design system inside a product team today, with checks on the merge path. How that works at MixShift

The design-system operating loop

The design-system operating loop. Diagram described in text.

Stages:

  1. Strategy and principles. What the system is responsible for, and what it deliberately does not cover.
  2. Standards and foundations. Tokens, components, patterns, accessibility requirements, documentation.
  3. Contribution. How teams propose new components, variants, and changes.
  4. Validation and approval. Design, engineering, and accessibility review, and technical testing. Marked: Decision.
  5. Release and migration. Versioning, communication, implementation guidance, deprecation.
  6. Adoption. How product teams discover, use, and contribute back.
  7. Measurement. Adoption, drift, exceptions, duplication, maintenance cost, quality, fed back to strategy.
  8. Ownership and governance. Connected to every stage. Marked: Owner.

Connections:

  • Strategy and principles leads to Standards and foundations
  • Standards and foundations leads to Contribution
  • Contribution leads to Validation and approval
  • Validation and approval leads to Release and migration
  • Release and migration leads to Adoption
  • Adoption leads to Measurement
  • Measurement leads to Strategy and principles
  • Ownership and governance leads to Strategy and principles (optional or feedback path)
  • Ownership and governance leads to Standards and foundations (optional or feedback path)
  • Ownership and governance leads to Contribution (optional or feedback path)
  • Ownership and governance leads to Validation and approval (optional or feedback path)
  • Ownership and governance leads to Release and migration (optional or feedback path)
  • Ownership and governance leads to Adoption (optional or feedback path)
  • Ownership and governance leads to Measurement (optional or feedback path)
A healthy design system is a managed lifecycle, not a finished library. The component library is one part of it; governance, contribution, adoption, and measurement keep it alive.

Key deliverables

  • Production tokens and components, built in your codebase
  • Design-system operating model
  • Roles and ownership matrix
  • Contribution and governance workflows
  • Component lifecycle framework
  • Documentation architecture
  • Release and migration process
  • Adoption roadmap
  • Templates and automation foundations
What I doHow the engagement runs
  • Build or rebuild tokens and production components in your codebase
  • Define ownership across design, engineering, product, and accessibility
  • Establish contribution and approval workflows
  • Create component lifecycle and maturity models
  • Define versioning, release, migration, and deprecation practices
  • Connect Figma, code, documentation, tokens, and repositories
  • Establish intake, exception, and escalation processes
  • Define adoption and system-health measurements
  • Introduce AI-assisted documentation, auditing, and maintenance where useful

Outcome

Your design system becomes a governed, measurable, and maintainable organizational capability instead of a component library that gradually falls apart.

An engagement can start from the build, from the operating model, or both, depending on where your system is today.

04 · Custom engagement

Team Knowledge System

Create an operating system for how your organization captures knowledge, makes decisions, and moves work forward.

I map how information moves through the organization, then create the structures, workflows, and automations that make that information useful.

ProofThe workflows I run my own product, content and operations work on are public. See how I run my own work

How organizational knowledge becomes action

How organizational knowledge becomes action. Diagram described in text.

Stages:

  1. Signals enter. Customer feedback, Research, Meetings, Product data, Team conversations, Operational events.
  2. Capture. Through defined channels, not private notes and chat threads.
  3. Structure and connect. Categorized, linked to projects, owned, and given a status.
  4. Synthesize. Patterns, context, and relevant prior decisions surfaced. Marked: People + AI.
  5. Decide. What was decided, why, who owns it, and when to revisit. Marked: Human decision.
  6. Execute. Projects, tasks, experiments, communications, operational changes.
  7. Learn. Results, exceptions, and new knowledge return to the system.
  8. Ownership.
  9. Permissions.
  10. Maintenance.

Connections:

  • Signals enter leads to Capture
  • Capture leads to Structure and connect
  • Structure and connect leads to Synthesize
  • Synthesize leads to Decide
  • Decide leads to Execute, becomes work
  • Execute leads to Learn
  • Learn leads to Structure and connect, feeds back (optional or feedback path)
Organizational knowledge becomes valuable when it can reliably influence decisions and execution. The system turns information into coordinated action and keeps what the organization learns, with ownership, permissions, and maintenance underneath every stage.

Key deliverables

  • Operational and knowledge-flow map
  • Workspace and information architecture
  • Decision, project, meeting, and documentation templates
  • Ownership and status conventions
  • Automation workflows
  • AI search or retrieval setup where appropriate
  • Governance and maintenance guide
  • Team onboarding and rollout plan
What I doHow the engagement runs
  • Map how information enters, moves through, and leaves the organization
  • Identify duplicated work, missing ownership, and approval bottlenecks
  • Create a clear information architecture
  • Define reusable workflows for projects, decisions, meetings, and handoffs
  • Connect organizational knowledge to execution and accountability
  • Introduce appropriate automation and AI-assisted retrieval
  • Establish governance and maintenance practices

Outcome

Your team can find what it knows, understand what was decided, and move work forward without depending on scattered documents or one person's memory.

This is not simply a tool setup. The tools support a larger system for organizational memory and execution.

05 · Custom engagement

AI Delivery System

Move from individuals experimenting with AI to a repeatable and controlled product-delivery system.

I design the workflows, technical foundations, human review points, and quality controls that help teams use AI throughout design and software development.

ProofZengin puts design-system rules inside coding agents, through an MCP server, an edit hook and CI. See how Zengin works

The AI-assisted product delivery loop

The AI-assisted product delivery loop. Diagram described in text.

Stages:

  1. Intent. Product objective, User problem, Requirements, Constraints, Success criteria. Marked: Human.
  2. Structured context. Product knowledge, Design-system rules, Architecture, Repository conventions, Prior decisions, Security boundaries.
  3. AI-assisted production. Research synthesis, UX exploration, Prototyping, Code generation, Documentation, Test generation. Marked: AI-assisted.
  4. Automated validation. Tests, Type checking, Linting, Accessibility checks, Design-system validation, Security checks. Marked: Automated.
  5. Human judgment. Product quality, User experience, Technical direction, Risk, Ethics, Approval. Marked: Human decision.
  6. Release. A controlled change reaches users.
  7. Evidence and learning. Usage, failures, feedback, and team observations.

Connections:

  • Intent leads to Structured context
  • Structured context leads to AI-assisted production
  • AI-assisted production leads to Automated validation
  • Automated validation leads to Human judgment, passes checks
  • Human judgment leads to Release, approved
  • Release leads to Evidence and learning
  • Evidence and learning leads to Intent, updates intent (optional or feedback path)
  • Evidence and learning leads to Structured context, updates context (optional or feedback path)
AI becomes useful at scale when it operates inside structured context, automated controls, and human decision-making. It accelerates production, but it does not own intent, judgment, or accountability.

Key deliverables

  • AI-assisted product-delivery workflow
  • Repository and project-context structure
  • Reusable instructions and workflow templates
  • Human approval and escalation model
  • Quality-control and testing gates
  • Automation recipes
  • Governance and safety guidelines
  • Pilot implementation using one real workflow or product slice
  • Team adoption roadmap
What I doHow the engagement runs
  • Map the current path from idea to production
  • Identify where AI can safely accelerate research, design, development, testing, and documentation
  • Define human review points and quality gates
  • Create reusable project instructions, context structures, prompts, and templates
  • Establish repository conventions and agent-ready documentation
  • Connect design-system rules to implementation workflows
  • Add automated testing, validation, and review where practical
  • Define security, access, and change-control boundaries

Outcome

Your team gains a repeatable way to use AI for faster product delivery without sacrificing human judgment, technical quality, or organizational control.

Why trust the work

The engine is public. So is the work of governing one inside a team.

The seven rule kinds, each with its family and what it catches

Detection · open source

Zengin

A deterministic engine, twelve packages on npm, MIT. Tested against three unrelated public codebases with no hand-written definitions, every finding read and classified by hand, and the engine's own false positives published rather than quietly fixed. Those runs found a typo shipped inside a widely used component library and dead classes that had rendered nothing for years.

Deterministic engineMCP + CI + edit hookPublic field tests
zengin.timurtek.com (opens in a new tab)
MixShiftThe system is the client's. The method is described, not shown.

Adoption · inside a team

MixShift

A system nobody adopts is worthless, and the real risk is that a team routes around it by the second sprint. I run a 175-component design system inside a product team today, with checks on the merge path and contribution and review practice around them. That operating half is what the three system-setup services are built from.

175 componentsMerge-path gatesContribution model
How that works in practice

Engagement model. Scope, fee, and delivery dates are agreed before work begins. Any changes are discussed and approved together. Custom system work is scoped the same way, from the problem rather than from a rate card.

Access and confidentiality. Access is agreed for each engagement. Audits require read-only repository access; implementation work uses the permissions and review process we agree together. I work within your approved environment and only use AI tools you approve. An NDA is available on request.

Start with the audit or a motion system, or tell me what is breaking.

A short call, no sales flow. If it is not a fit, I will tell you on the call and point you at what would help instead.

Discuss a custom system