simon.fyi

Portfolio built with Next.js and Design System 33

2026Design SystemReactNext.jsPortfolio

simon.fyi is my personal portfolio website, built as a real-world implementation of Design System 33. It’s not a “demo UI kit”—it’s a working React application that proves the system can support real pages, real content, and real product constraints while staying consistent.

This site functions as a living reference: every layout decision, component usage, and styling rule goes through the same token and theming foundations that I deliver to teams.

The goal

I built simon.fyi to validate—and continuously improve—Design System 33 under real conditions:

Ship a polished website fast without sacrificing consistency.
Prove that the component and token architecture holds up beyond isolated components.
Prevent design drift by enforcing shared patterns across pages and sections.
Prove that Design System 33 is a package and ready to use.
Demonstrate how a design system supports both delivery speed and maintainability.
Improve on the go; some components required adjustments.

What I worked on

Design System

The portfolio is implemented on React and uses Design System 33 as its UI foundation. That means the site’s UI is composed of the same primitives you’d expect in a production product: layout components, typographic scales, interactive components, and reusable patterns—rather than one-off page styling.

The platform does not have any component-level styling; only global-level styling. Making a clear separation of concerns and a single source of truth for UI decisions.

Implementation logic

Simon.fyi is intentionally built to reflect how enterprise teams should work with a design system:

Pages are assembled from reusable components instead of being page-specific.
Components expose clear, repeatable APIs (variants and props are intentional).
Tokens replace arbitrary values, which removes “close enough” styling decisions.
Common patterns (sections, headings, spacing, grids) are standardized so new pages don’t introduce drift.
A Design System is not “rocket science” and can be achieved today.

The result: consistency becomes the default, and the UI stays coherent as the site grows.

Removing design drift

A portfolio site is deceptively good at exposing design drift: every page is different, content changes frequently, and small inconsistencies become obvious.

Design System 33 prevents drift here by:

Centralizing visual decisions in tokens and theme values.
Reusing the same layout and typography patterns across pages.
Making “the right way” the easiest way—so exceptions are rare and explicit.

This is exactly the dynamic teams face when multiple developers contribute across multiple squads.

Tech Stack

Next.js
React
Design System 33
Styled Components
TypeScript
Figma

Why this work matters

simon.fyi proves that, Design System 33 works where it matters most: in a real React product with real constraints, not in a controlled component sandbox. By using the system to build complete pages end-to-end, it becomes immediately obvious where tokens, theming, and component APIs are strong—and where they need to evolve—so the Design System stays practical and adoptable

This kind of “living reference implementation” is also how teams align faster: designers, developers, and stakeholders can point to a shipped result rather than interpret guidelines differently. It demonstrates that consistency is not a one-time clean-up project, but an outcome of having the right foundations and making the consistent option the easiest option.

Ultimately, it shows what I deliver to clients: a system that reduces drift, improves maintainability, and helps teams ship faster with confidence—and I’m available to apply the same approach to your React/Next.js platform.