Problem

The portfolio needed a hero element with more signal than a static block of text. The hard part was making it reusable instead of flashy once.

Context / users

This started as a reusable identity card with fallback profile data and motion. It later informed the production hero card and the live case-study demo path.

Solution

I split the work into a card component, a shared animation hook, and a route-level live demo mapping. That kept the motion logic reusable and let the production version diverge where needed.

• NeonProfileCard supports an optional profile prop with fallback data for name, role, tagline, status, avatar, and badges
• Badge handling is defensive: strings and object-shaped badge values are both tolerated, and non-array badge input collapses safely to an empty list
• MatrixSync renders a terminal-style status panel with phase-based color changes, attempt counts, and animated register cells
• useMatrixSync centralizes the timed animation loop, including randomized delays, phase changes, and reset behavior after repeated attempts
• The case-study route can inject a live demo component by slug instead of relying only on screenshots or static prose
• The homepage version uses Next/Image for the portrait and memoization on key hero components

Architecture

The experiment lives in `components/NeonProfileCard`, the production homepage version lives in `components/Hero`, shared motion lives in `hooks/useMatrixSync` and `components/ui/MatrixSync`, and the project route chooses which live component to inject via `app/projects/[slug]/page.jsx`.

Engineering Details

• • This is client-side interaction work for the component itself: no auth, no persistence, and no server mutation logic
• • The strongest technical decision is separating timed animation logic from the presentation layer. MatrixSync reads state; useMatrixSync owns sequencing and phase transitions
• • The hook is configurable enough to reuse: it accepts custom glyph sets and cell counts, which is why the standalone NeonProfileCard can use a different visual character set from the homepage card
• • The slug-driven project page makes interactive case studies a platform feature instead of a hard-coded exception
• • The project inherits shared app hardening: CSP nonce generation, security headers, import optimization, production console stripping, compression, and asset caching
• • The route layout generates metadata from project data, so the case study participates in the broader SEO and social-preview system even though the page itself is interactive

Outcome

• The experiment became part of the live homepage instead of staying isolated
• The animation logic now exists as a reusable hook-driven pattern rather than being buried inside one card
• The project detail system can showcase the component as a live hero, which is stronger proof than a static screenshot-only case study
• The work adds a distinct branded identity layer to the portfolio without requiring a separate application or deployment

Tradeoffs / Limits

• • The current live case study renders HeroOperatorCard as the hero, not the standalone NeonProfileCard, so the page should describe that distinction explicitly
• • There is no component-specific test coverage surfaced for this feature even though the repo has Jest configured at the project level
• • Validation is lightweight. The standalone card has safe fallbacks and badge normalization, but there is no formal schema validation for profile input
• • There is no project-specific screenshot or OG image, so this entry currently falls back to the shared default social preview image
• • Because this is a UI-engineering case study, outcomes are qualitative. The repo does not prove conversion or engagement metrics

Why It Matters

It is a UI-engineering project. The point is component design, animation abstraction, and demo integration.