Charalampos Boumparis
03Web design & development

Personal Portfolio

A custom Next.js portfolio designed as a flexible system for presenting technical work, creative projects, development notes and case studies.

Year
2026
Status
Active
Role
Design and development
Technologies
Next.js, React, TypeScript, Tailwind CSS

Portfolio system / Project stage

01

Why rebuild it

The portfolio began on simpler hosted platforms that were useful for putting work online quickly, but they became increasingly restrictive as the projects themselves became more varied.

A game-development project, an exploratory product concept, technical work and development notes do not all benefit from being presented through the same generic project-card structure. The new site needed to give each kind of work enough space to explain itself while maintaining a consistent identity across the portfolio.

Rebuilding the site from scratch therefore became more than a visual redesign. It became an exercise in deciding how my work should be organised, connected and presented as it continues to change.

02

Designing around the work

The site is organised around a small number of clear areas: Work for project case studies, Notes for shorter observations and development thinking, About for broader context, and the homepage as an entry point into all three.

The interface is intentionally restrained so that the projects remain the main source of visual identity. Rather than treating every project as an identical card or forcing the homepage into a conventional marketing layout, the composition is built around the content that actually exists.

Cross-links between projects, notes and the About page also help the site behave more like one connected body of work than a set of isolated pages.

03

Building a content system

The implementation uses Next.js with typed content stored directly inside the project rather than relying on a CMS. Projects, notes and profile information each have their own structured data sources, while shared components handle the parts of the interface that genuinely repeat.

This keeps the site simple enough to maintain while still allowing content to propagate across multiple surfaces. A project record can appear on the homepage, Work index, project navigation, metadata and related content without maintaining separate versions of the same information.

The architecture is deliberately modest. The goal is not to build infrastructure for hypothetical future requirements, but to keep the site understandable while leaving enough room for the portfolio to grow.

04

Creating a visual language

The visual system uses a dark navy foundation, warm off-white text, restrained blue accents, thin borders and IBM Plex typography. Most hierarchy comes from spacing, proportion, grid placement and type rather than shadows, decorative effects or heavily styled containers.

A shared editorial grid and consistent gutters give the pages a common structure, while individual compositions are allowed to vary depending on what the content needs. The intention is for the site to feel technical and deliberate without becoming visually sterile or competing with the work itself.

The design has been refined iteratively as real content has been added. Decisions are tested against actual project titles, long-form writing, metadata and different page types rather than being designed around placeholder content.

05

Letting projects tell different stories

One of the more important architectural changes was moving away from a rigid project-page template.

Earlier case studies relied on section position to determine layout and media treatment. That worked while every project followed roughly the same structure, but it became restrictive as the projects developed different kinds of stories.

The current system keeps a shared project shell while allowing individual sections to declare their own layout and visual intent. Odyssey can emphasise information architecture and system diagrams, the game project can focus on development experiments and environments, and the portfolio itself can explain technical architecture without forcing all three into an identical sequence.

That balance between consistency and project-specific composition has become one of the central ideas behind the Work system.

06

Responsive and accessible by default

Responsive behaviour is considered as part of each composition rather than as a final step where desktop columns are simply stacked. Reading order, media placement, navigation, typography, spacing and touch targets change where necessary across smaller screens.

The site also uses semantic HTML, visible keyboard focus states, logical heading structures and accessible navigation behaviour. Motion is deliberately limited and reduced-motion preferences are respected.

Next.js metadata, sitemap and robots configuration provide the basic search and indexing infrastructure, while the site remains prepared for a production domain and richer metadata when those become relevant.

07

An evolving system

The portfolio is live as a working project rather than a finished design artifact. Its structure will continue to change as new work is added and the existing projects become more substantial.

That is part of the reason for building it this way. Instead of rebuilding the entire site whenever my work changes direction, the underlying system can evolve with the content while preserving a consistent visual and technical foundation.

The site therefore serves two purposes at once: it documents the work I am doing, and it is itself an ongoing example of how I approach design, frontend development and information architecture.