Ashlar

A production-ready package that makes consistency the default

2025 - nowDesign SystemReactstyled-componentsTypeScriptFigma

Ashlar (formerly Design System 33) is the design system I built to help teams ship UI faster without sacrificing consistency. It’s a React and styled-components based Design System and theming foundation that reduces “design drift” by turning design decisions into reusable tokens, predictable component APIs, and a shared implementation logic across projects. Since 2025, more than 1,000 hours of my own time have gone into it.

Read more about the “Why”, “What”, and “How” below.

If you’re looking for a React / Design System specialist to help build, implement, and scale your system, let’s get in touch. I can kickstart your project and keep it going.

Product website: ashlar.design

Why !?

People often ask me — why invest so much time in building a complete Design System from the ground up?

The answer is rooted in how I work. As a freelance developer, most of my projects live behind private repositories and NDAs. I collaborate with teams, solve real problems, and ship production code — but once the work is done, it quietly disappears into client infrastructure. I can’t show code, I can’t share internal tools, and yet, that’s where most of my professional growth happens.

At some point, that started to feel limiting. So, I decided to build something that could live in the open — a project that would mirror how I work day-to-day, showcase my technical process, and express my approach to design systems as a craft.

That’s how Ashlar came to life. It’s a hands-on demonstration — not a theoretical exercise — built with the same principles and tools I use on real client projects. It covers the full spectrum: project setup, design tokens, component architecture, Storybook documentation, and packaging for reusability. Every decision, from folder structure to theming logic, is intentional and scalable.

In short, it’s my way of opening up the work I usually can’t share — a transparent look at how I design and build systems that bridge creativity, structure, and technology.

Assumption is the mother of all f**k ups.

The challenge: design drift at scale

As teams and platforms grow, UI tends to fragment: the same component gets rebuilt slightly differently per page/person/team, “close enough” styling decisions slip into production, designers and developers interpret patterns differently, and changes become risky because the UI isn’t centralized. Inconsistency has entered the room. It isn’t only a visual issue—it’s a delivery issue that slows teams down, causes regressions, and makes it harder to maintain product quality.

It’s also a coordination problem. When multiple squads ship under pressure, small deviations become the new normal: an extra spacing value here, a slightly different hover state there, a one-off layout “just for this page.” Over time, those micro-choices multiply into parallel implementations, more review cycles, and a bigger QA surface area—making even simple changes feel risky.

The solution isn’t stricter policing; it’s better foundations and a single source of truth. When tokens, theming rules, and reusable components encode decisions once—and make the consistent option the easiest option—teams stop re-solving the same UI problems. That’s when velocity improves, change becomes safer, and the product stays cohesive as new features, pages, and teams are added.

The solution: a structured system

Complete Package

Ashlar is a React codebase (package) built around styled-components. Designed to serve as a shared UI foundation across codebases, so teams can build product features on top of stable primitives rather than reinventing the same decisions.

What’s included (high level):

250+ React components in TypeScript, from Button and DataTable to calendar scheduling, Gantt, 16 chart types, and AI chat UI.
Active development on today's standards: React 19, TypeScript 7, and Vite 8.
A structured component library with a docs page for every component, 2,500+ Storybook stories, and clear “what it is” and “how to use it” conventions.
A theming layer that supports brand or product variations without rewriting components.
A token-driven styling approach to keep things like spacing, color, and typography consistent.
Implementation patterns that guide teams toward the same solutions (by default).
Built into a package for easy implementation, with size budgets per export and server-safe imports.
i18n built in (English, Dutch, and pseudo-locales for testing) with RTL/LTR support.
11 providers for color scheme, density, motion, i18n, links, undo, heading levels, and more.
Accessibility as a contract: 100+ automated audits, from target size and focus-not-obscured to reduced motion and forced colors.
Unit tests, visual regression, and Lighthouse checks.

Design Tokens

This is the foundation that makes the system consistent and maintainable. Instead of using arbitrary values, the UI is built from named design decisions; it’s a new shared language.

Benefits of a token-driven approach:

Core with default, color palette, and aliases like ‘brand primary’ and ‘error’.
Color and variants: ‘default’, ‘hover’, ‘disabled’, etc.
Typography: font family, font size, line height.
Spacing and layout.
Borders, shadows, and other visual primitives.
A tiered structure on the DTCG spec (core, alias, and component tokens), exported to CSS variables, SCSS, a Tailwind preset, and JSON Schema.

Tokens make alignment easier because they give designers and developers the same vocabulary—and they reduce drift because the system discourages “random values.” Adding strict rules and blocking code linting even disallows certain styling. Plus, the JSON files are easy to read, transform, and share.

Theming

Theming in Ashlar is designed for real-world product needs —brand differences, product lines, or client-specific styling—without forking component code. It’s one system for multiple looks.

How theming helps:

Components stay stable while themes change the “skin”.
Visual decisions live in the theme, not across components — separation of concerns.
Teams can introduce new themes or update branding with controlled impact.
One codebase to support multiple platforms.
Light and dark modes, presets, high contrast, and density scales built in.

The result is faster iteration with less risk, because changes are centralized and intentional.

Consistency

Consistency stopped being optional
Ashlar was built for the moment a product outgrows “best effort” UI. When multiple teams ship in parallel, consistency can’t rely on memory, taste, or review feedback—it has to be encoded into the system.

Consistency is king because it compounds: it improves UX, reduces bugs, increases speed, and makes onboarding new team members easier.

By moving decisions into tokens, theme contracts, and typed component APIs, the system makes consistency the default rather than requiring recurring negotiation. That reduces rework, speeds up reviews, and makes changes safer because teams are extending a shared foundation rather than introducing new interpretations.

In short: once you scale, consistency isn’t a preference anymore—it’s infrastructure.

Consistency is king.

Single source of truth

A Design System only works when teams trust it, which comes from having a centralized place for decisions.
Ashlar is built around a “single source of truth”: tokens and theme contracts define the visual rules, and the component library implements and reuses those rules. Design tokens are commonly used for this purpose—capturing design decisions in one place so changes can be tracked and applied consistently across a product.

Without an SSOT, every squad ends up maintaining its own “truth”: Figma says one thing, code says another, and quick fixes turn into permanent exceptions. With an SSOT, changes become intentional and repeatable: update a token, theme value, or component once, and the UI updates everywhere the system is used. That’s how you scale consistency without scaling meetings, and how you reduce drift while still moving fast.

Predictable patterns

The system is built around “agreements & one way of doing things,” so teams don’t have to debate every new component. A lot of time is wasted during unnecessary meetings.

Core principles in the implementation:

Components expose a consistent API (props and variants are intentional, not ad-hoc).
Styling decisions are mapped to tokens and theme values instead of one-off CSS values. Only layout/display/render styles are written.
Composition is preferred over one-off exceptions, keeping the library scalable.
Defaults are opinionated: the easiest path is also the consistent path.

This approach makes it easier for both developers and designers to contribute without introducing subtle UI differences. Someone has to make a “solid case” when there’s a request to change an already existing color palette, component property, or token.

Removing design drift

Most UI inconsistencies don’t come from “bad developers”. It typically arises when multiple squads ship under time pressure, design decisions aren’t fully defined (or key states are missing), teams lack shared foundations such as tokens, components, and rules, and there’s a gap between design intent and implementation reality.

Ashlar solves this by making consistency the path of least resistance:

Shared components replace duplicated implementations.
Tokens and theming reduce one-off styling.
Clear patterns make contributions predictable.
The system becomes the source of truth for UI decisions.
UI becomes coherent across features and squads.
Delivery speeds up (less rework, fewer debates, fewer regressions).
Designers, Developers, and Product Owners are aligned.

Alignment of teams

A design system only works if teams can — and want to — adopt it. Ashlar is built to support alignment by creating a clear contract between design and development:

All designs (variations) are available in a file, e.g., Figma.
Design intent is captured in tokens and variants.
Components are documented and aligned on properties.
The system encourages shared ownership and repeatable contribution patterns.

The practical outcome: fewer discussions about UI “how,” more focus on product “what” and “why.”

How Ashlar is built

Since April 2026, Claude Code has sped up the building. I still design, decide, and review all the code and every change.

I also wrote the rules: my own Claude Skills (build a component, build an icon, run an audit, turn a brand into a theme) and MDX convention files with guidelines for tokens, accessibility, i18n, RTL, theming, and more. Every change has to meet them, whether I write it or Claude does.

How the loop works:

I decide what gets built and write the intent in Jira.
A routine sharpens each ticket until it’s clear enough to build.
Claude builds with my skills and conventions, opens a PR, and runs the audits, often overnight.
A nightly audit checks the whole system and files new tickets for me to triage.
I review every PR: merge, push back, or rewrite the ticket.

Since April 2026, more than 1,000 tickets have moved to Done. Every one passed my review.

2026 so far

Winter: the foundations. Storybook, theming, a color palette, a pixel-perfect 16px icon set, and the first components.
Spring: my own Claude Skills and Claude Code routines on the Jira board, followed by RTL, i18n, and WCAG 2.2 checks.
Summer: a tiered token system on the DTCG spec, brand themes, Gantt, interactive charts, and a docs page for every component.
Autumn: drag-and-drop calendar scheduling, combo charts, month and year pickers, and the move to TypeScript 7 and Vite 8.

Staying current

I follow what’s changing in design systems and study new releases throughout the year. In 2026 that included Fluent UI Web Components 3.0, Nord 5.0, Vuetify 3, and shadcn’s OKLCH tokens. The best ideas become tickets on the board.

Next up: Figma

Connecting Figma, so the design is fully linked to the tokens and the codebase, with updates flowing through automatically.

Tech stack

React 19
styled-components
Storybook
Design Tokens
TypeScript
Vite
Figma
Vitest, visual regression with Chromatic, and Lighthouse
i18next
Claude Code

Why this work matters

Ashlar matters as a portfolio project because it demonstrates senior-level ownership: I’m not only building screens, I’m building the system that makes screens consistent, scalable, and maintainable. It shows how I think about UI as infrastructure—tokens, theming, component APIs, documentation patterns, and the guardrails teams need to move fast without breaking quality.

It also proves my work in a way a “component demo” can’t. A Design System only becomes real when it’s used across real pages, real content, and real constraints, and that’s exactly what I build and validate through production usage. This makes the portfolio a living reference of how I design for reuse, prevent fragmentation, and keep implementation aligned with intent.

Finally, it positions me clearly for the work I want more of: React and Design System engagements that start with alignment and continue into implementation and adoption. Instead of telling people I can remove inconsistency and speed up delivery, this project shows it—through a concrete system, a clear approach, and a buildable foundation.

Where I come in

I could be the React / Design System Specialist your team needs.
Currently at Stedin and open to new projects from January 2027, for build, implementation, or support days depending on your needs.

Connect and discuss how I can help you succeed.

Contact me