PORTFOLIO

A portfolio site designed so that a recruiter who already decided to look doesn't have to spend extra effort — projects visible immediately, no clicking required.

[ GITHUB → ]
RELEASE_DATE[ completed ] Feb 2026
ROLEFULL-STACK DEVELOPER (SOLO)
TIMELINEFEBRUARY–APRIL 2026 (~2 MONTHS)
COMMITS18
STATUSCOMPLETED
TECH_STACK
Next.js 16TypeScriptVanilla CSSFramer MotionGSAPThree.jsMDX
[ 01 ]

PREMISE

"A person who landed on the portfolio has already decided to look. Every extra click is a cost that can be eliminated."

CONTEXT

A portfolio is the first impression for a recruiter who is already interested. The site's architecture should respect that — not require extra actions to get to what matters.

APPROACH

One continuous view instead of a navigation structure. Projects, process, and contact — all accessible without switching between pages.

[ 02 ]

ONE-PAGER

Many portfolios work the same way: a home page with a button, a projects list after one click, a project after another. Every transition is a decision the user has to make.

There's a well-known experiment about default organ donation consent — countries with opt-in forms get a few percent, countries with opt-out forms reach nearly a hundred. Not because people hold different values — because the default state matters.

[ decision ]HERO → TIMELINE → ABOUT → FOOTER

I removed the separate /projects page and project cards as an entry point. The timeline on the home page shows projects immediately — no click required. An about section sits between the timeline and the footer, before the visitor reaches the end of the page.

[ insight ]COGNITIVE COST

Every action a user has to take is a coin they spend. A portfolio should be designed so they spend those coins on content, not navigation.

[ 03 ]

MDX SYSTEM

Each project is a folder: meta.json for metadata, config.ts for the visual theme, pl.mdx and en.mdx for content. No central database, no external dependencies.

OTHER APPROACHESMDX FOLDER-BASED
SchemaUniform across all projectsEach project can have its own components
DependenciesExternal CMS or APILocal filesystem
Per-project codeImpossible in JSON/XMLComponents in content/projects/[slug]/
Adding a projectAdmin panel or API callOne workflow: brief → MDX files
[ insight ]INDEPENDENCE

The system will never surprise me with an external service requirement. Files are local, the format is open, migration doesn't require rewriting logic.

[ 04 ]

ANIMATIONS

Three different tools for three different jobs — not because more is better, but because each has a different capability-to-cost ratio.

FRAMER MOTION

Micro-interactions, UI state, theme toggle. Lightweight, React-state-reactive, sufficient for simple animations.

GSAP

Hero animation (velocity-driven skew), SectionScroller, scroll-triggered sequences. Smooth, precise, essential for complex timelines.

THREE.JS — 3D ONLY

Wireframe cube in the footer. Three.js is the right tool for 3D and that's the only place it's used — EdgesGeometry + LineSegments, alpha canvas, cleanup on unmount.

[ 05 ]

RETROSPECTIVE

This is the only project with no external deadline or client — all the time pressure was self-imposed. The real challenge wasn't a knowledge gap, it was the lack of a natural stopping point: it's easy to keep polishing animations and structure instead of calling a version done. I ended up setting that boundary myself — once the content and case studies were complete, further visual polish stopped being the priority.

Outcome

Portfolio live with a custom domain, responsive on mobile. Adding new projects requires no changes to application code — just MDX files in a new folder. Next: more projects in the timeline.