Building a production portfolio with structured content, automated deployment, live infrastructure telemetry, and measurable performance.
I originally needed a place to put my résumé, certifications, and projects. Something more useful than a LinkedIn profile, where I could show what I was building and explain the decisions behind it.
As the projects grew, the website became a project of its own. What began as a professional landing page evolved into a Next.js application with dedicated case studies, technical writing, a Notion-backed content workflow, and live metrics from my homelab. It also taught me to think about deploying, measuring, and maintaining an application rather than only how it looks.
Stack: Next.js, React, TypeScript, GitHub, Vercel, Notion, Prometheus, Grafana Alloy, Grafana Cloud, Google Lighthouse.
Designing around the work
I wanted visitors to see more than a collection of technology badges. A project card can introduce the work, but a case study has room for the problem, the implementation, what went wrong, and what I learned. That structure became the foundation of the Projects section.
The IT Odyssey identity also needed to feel consistent across the site. I worked toward a recognizable visual language for the hero, project artwork, navigation, and technical content. There were plenty of design iterations, but I eventually reached a point where changing the layout again would offer less value than building something new to document.
That was an important shift. The website exists to support the engineering work, not compete with it.
Separating content from presentation
I use Notion to organize articles and project case studies, with structured fields for descriptions, tags, cover images, slugs, and publication status. The website turns those entries into a consistent reading experience.
This also makes maintaining the portfolio manageable. I can update a case study as a project changes without redesigning its page. Longer backlogs and implementation plans stay in my working documents, while the published articles focus on the story and evidence a reader actually needs.
One of the harder lessons was editorial. I initially leaned too far toward formal, mechanical technical writing. I still want precise terminology and honest limitations, but the explanation should sound like an engineer describing what happened and why a decision mattered.
Getting changes into production
The application is maintained in GitHub and hosted on Vercel under my custom domain, jeff.itodyssey.io, with HTTPS.
The hosted deployment workflow removes much of the server maintenance that would otherwise distract from the site's purpose. It still gives me a real application to update, deploy, check, and troubleshoot. Source control and automated hosting are useful, but I don't consider an automatic deployment equivalent to a comprehensive, tested CI/CD pipeline.
I also learned to treat production checks as their own task. A page can look correct on my workstation while having a broken link, an awkward mobile layout, or content that no longer reflects the current state of a project.
Letting the homelab speak for itself
The most distinctive part of the site is the live homelab telemetry. Rather than simply listing Prometheus, Kubernetes, and Grafana among my skills, I wanted visitors to see a small window into a system I operate.
Prometheus collects measurements in the homelab. Recording rules produce selected aggregate metrics, and Grafana Alloy sends the approved series outbound to Grafana Cloud. The website renders a compact view of utilization, container activity, scrape health, and Kubernetes status.
That connection forced me to think carefully about the boundary between private infrastructure and public evidence. The portfolio needs a useful summary, not internal addresses, hostnames, or detailed resource identifiers. The public measurements are therefore intentionally narrower than my local operational dashboards.
The telemetry is also not a substitute for a full health check. A green scrape target means metrics collection succeeded; it doesn't mean every application function is healthy. I wanted the displayed numbers to be meaningful without overstating what they prove.
View the live portfolio telemetry
Measuring quality instead of guessing
Before moving the website into maintenance mode, I ran Google Lighthouse audits against the production homepage on both emulated desktop and mobile environments.
The desktop audit returned 99 Performance, 100 Accessibility, 100 Best Practices, and 100 SEO. Its Largest Contentful Paint was 0.8 seconds, Total Blocking Time was 0 milliseconds, and Cumulative Layout Shift was 0.
The mobile audit, using an emulated Moto G Power and Slow 4G conditions, returned 93 Performance, 100 Accessibility, 100 Best Practices, and 100 SEO. First Contentful Paint was 0.9 seconds, Largest Contentful Paint was 3.2 seconds, Total Blocking Time was 30 milliseconds, and Cumulative Layout Shift remained 0.
The mobile Largest Contentful Paint is an area I could improve, but it isn't a reason to keep redesigning the entire site. The results are synthetic snapshots rather than guarantees about every visitor's experience, and PageSpeed Insights did not have sufficient real-user field data for this site at the time of the audit.
Baseline recorded October 18, 2026. Scores describe the audited homepage and test settings, not every route or device.
Knowing when to stop building
An interesting part of this project was deciding when it was finished enough.
After updating the résumé links, reviewing the case studies, refining the featured project description, and collecting the Lighthouse baseline, I stopped finding changes that would meaningfully improve the site's purpose. There's always another animation, component, or minor visual adjustment to make, but those aren't automatically valuable.
Maintenance mode doesn't mean abandoning the site. I'll still correct broken links, publish new project milestones, update career information, and respond to genuine quality regressions. It means treating stability and useful content as more important than constant redesign.
That may be the most relevant lesson from this project: shipping something is only part of the job. Being able to operate it, measure it, document its limitations, and decide where to spend effort next is engineering too.