What I built.
A responsive React portfolio designed to make projects and professional information easy to explore. Content is separated from presentation so it can grow with new projects, experience and accomplishments.
- Searchable, filterable project collection with detailed case studies.
- Dedicated CV view with a print-friendly layout.
- Responsive navigation, keyboard-accessible dialogs and reduced-motion support.
- Automated browser checks for the core user journeys.
Under the hood.
React
Filtering, dialogs and route state
JavaScript content modules
Project records and article sections
CSS
Responsive journal and project artwork
Playwright
Browser interaction checks
- Project metadata
- Story + technical notes
- Searchable cards
- Native dialog reader
Retiring the decorative first version
The first version leaned too heavily on abstract visuals. I wanted someone to arrive and understand that I am a developer, see what I have built and find my professional experience without having to work for it.
Content is data; the reader is a component
The projects live outside the React layout. Stories attach by project ID, and the card summary, technology tags and reading time are derived from that content. The same project can then appear in the grid, the quick navigator and the CV without duplicating its identity in three places.
The article renderer supports narrative sections, a stack breakdown, a request-flow illustration and labelled code examples. I do not need every project to contain every block. A redirect service deserves a request trace; a brand website probably does not.
The browser already has a dialog primitive
The project reader uses the native dialog element and showModal. Opening it records the active element, locks background scrolling and focuses the close control. Closing restores focus to the trigger. The keyboard navigator is a separate dialog, opened with Ctrl or Command plus K.
The browser checks exercise those transitions, as well as filtering, the CV route and mobile overflow. A useful lesson from testing was to wait for React content after a hash change: the URL can change before the next view has committed.
Testing the transitions, not just the screenshot
Opening a project should answer the next questions: why does it exist, what did I contribute and what is actually implemented? That is why the stories are grounded in my CV and the local project source rather than generic descriptions.
How I check it
Playwright checks cover filtering, project dialogs, focus restoration, CV navigation and responsive layouts. The site is still growing, but the core interactions should remain dependable as the collection gets larger.