Next.js · TypeScript · Git · Vercel · Structured case studies
Overview
I designed and built this portfolio as a professional platform to present my work as an Automation Developer.
The goal was not only to create a personal website, but to build a structured case study system that explains projects clearly: what problem was solved, what my role was, how the system was designed, which technologies were used, and what proof can be shown publicly without exposing private company or customer data.
The portfolio separates automation systems from frontend and product builds, so visitors can quickly understand the difference between operational workflow systems, internal tools, and web/product prototypes.
The challenge
My work includes many automation workflows, internal tools, Slack apps, document workflows, frontend prototypes, and Microsoft 365 integrations.
The challenge was to present this experience in a way that is professional, readable, and trustworthy without overwhelming the visitor with too much technical detail on the homepage.
The website needed to show enough proof to be credible, but also keep sensitive company data, customer data, workflow exports, credentials, internal URLs, and private operational details protected.
What I did
I designed, wrote, structured, and built the portfolio platform myself.
My work covered the full platform: the portfolio structure, writing and refining the project case studies, separating automation systems from frontend/product builds, and designing the project cards and detail pages.
I added the proof/evidence sections across the case studies, improved positioning and professional messaging, and built the responsive layouts.
For deployment, I used Git for version control and Vercel for auto-deploy on push, tested production pages after each update, and fixed build and routing issues along the way.
Platform structure
Core modules
Homepage positioning
The homepage explains who I am, what kind of systems I build, and what kind of work I want to show. The content is written to avoid exaggerated claims and to guide visitors toward selected case studies instead of forcing all project details into one long page.
Project grouping
Projects are grouped into automation systems and frontend/product builds. This prevents confusion between operational automation systems and web prototypes or product experiments.
Case study pages
Each main project has its own case study page with a structured format: Overview, Problem, My Role, Architecture, Core Modules, Technical Decisions, Reliability, Impact, Tech Stack, Evidence sections and project-specific publication notes. This makes the portfolio easier to scan and more professional.
Proof / Evidence sections
Each case study includes a proof section explaining what can be demonstrated publicly, such as architecture diagrams, code excerpts, workflow descriptions, or cleaned repositories. This is important because many automation projects cannot expose raw workflow JSON, customer data, credentials, or company-sensitive details.
Iterative improvement workflow
The portfolio was improved through an iterative workflow: write, review, deploy, verify production, identify inconsistencies, and refine the content. This included fixing production build issues, checking broken links, aligning project titles, and making the homepage consistent with the case study pages.
Custom animation system
All motion is hand-rolled rather than pulled from a library: a WebGL fragment shader drives the hero ambient, the native View Transitions API morphs project cards into case study headers, a SplitText component cascades the hero name letter by letter, a seamless CSS marquee scrolls inline brand SVGs across the hero, and an IntersectionObserver hook handles section reveals. Every effect respects prefers-reduced-motion and is gated behind (hover: hover) where it touches hover state.
Technical decisions
Case studies instead of one long experience section
The Experience section is kept short and summary-level, while the case study pages contain the detailed implementation logic. This makes the site easier to read and prevents repeated content.
Clear separation of project types
Automation systems and frontend/product builds are separated because they represent different types of work. This makes the portfolio more honest and easier to understand.
Proof without exposing sensitive data
The portfolio shows architecture diagrams and code patterns instead of raw workflow exports. This protects company data while still demonstrating the technical work.
Git and Vercel workflow
The project uses Git for version control and Vercel for production deployment, with production checks after each change.
Hand-rolled WebGL and native View Transitions over libraries
The hero background uses a custom GLSL fragment shader instead of pulling in Three.js. Page navigation from project cards to case studies uses the browser-native View Transitions API instead of a routing library. Each decision keeps the bundle small while demonstrating that the underlying platform APIs are well understood.
The outcome
The portfolio became a structured professional platform instead of only a personal webpage.
It now explains my experience through selected, proof-backed case studies and shows both automation architecture and frontend/product thinking.
The main impact is clarity: visitors can quickly understand my role, the type of systems I build, the technologies I use, and the difference between operational automation systems and frontend/product builds.
Tech stack
Proof / Evidence
This case study is based on the live portfolio platform itself.
Public proof shown on this page
A platform structure diagram showing the portfolio architecture: homepage with summary, grouped project cards, individual case study pages with proof sections, Git-based iteration, and Vercel deployment.
What this case study demonstrates
Public code & documentation
Reusable component and hook patterns extracted from this portfolio: custom IntersectionObserver scroll-reveal hook, View Transitions navigation hook, hand-written WebGL hero shader (FBM noise with all six hard guards), per-letter SplitText reveal, seamless CSS marquee with inline brand SVGs, scroll-progress ring driven by SVG dashoffset, role-cycling typewriter state machine, SVG architecture diagrams on a row/col grid, and the consistent 9-section case study layout pattern. Includes documentation behind each design decision: why no Framer Motion, why minimal Tailwind, why no CMS.
Code excerpt: useScrollReveal hook
Every section on this page fades and slides up as it enters the viewport. That specific reveal is driven by a custom IntersectionObserver hook (about 25 lines of TypeScript), not Framer Motion. The observer self-disconnects after the first hit, so scrolling up and back down doesn't replay the animation. The broader portfolio runs four other custom systems alongside it: a WebGL hero shader, the View Transitions API for project-to-case-study navigation, a per-letter name reveal, and the brand-logo tech-stack marquee.
// useScrollReveal: IntersectionObserver hook
//
// Returns a ref and a boolean. Attach the ref to any element;
// the boolean flips to true the first time the element scrolls
// into view, then stays true forever. The observer
// self-disconnects after the first hit.
//
// Use case: trigger CSS transitions when content enters the
// viewport, without pulling in Framer Motion (~30kB gzipped)
// for what is fundamentally one boolean and a transition.
"use client";
import { useEffect, useRef, useState } from "react";
export function useScrollReveal(threshold = 0.15) {
const ref = useRef<HTMLDivElement>(null);
const [isVisible, setIsVisible] = useState(false);
useEffect(() => {
const el = ref.current;
if (!el) return;
const observer = new IntersectionObserver(
([entry]) => {
if (entry.isIntersecting) {
setIsVisible(true);
// Fire once, then stop observing. Never replay.
observer.unobserve(el);
}
},
{ threshold },
);
observer.observe(el);
return () => observer.disconnect();
}, [threshold]);
return { ref, isVisible };
}Full hook in snippets/use-scroll-reveal.ts. The repository also covers the typewriter state machine used in the hero, the SVG architecture diagram component used across all case studies, and the consistent 9-section case study layout pattern. The full portfolio source is not republished. The live site is the demo; the repository documents the patterns behind it.
Project Ownership & Transparency
This is my personal portfolio project. I designed, wrote, built, and deployed it myself to present selected automation systems, frontend/product builds, and proof-backed case studies. Where professional work is described, the public version uses anonymized summaries and safe technical explanations. The portfolio source code does not publish customer data, credentials, internal workflow exports, private operational files, or sensitive configuration.