This site is a Hugo static site I build and maintain myself. I wanted something I could update quickly, keep under version control, and shape to match how I actually present my work, rather than a hosted resume builder or a template I did not control.

It also gave me a real project to keep, not a one-time setup. What follows is how it is put together and the decisions behind it.

The Technology Stack

The stack is deliberately small, so the site stays fast and easy to maintain:

• Hugo: A static site generator. It builds the whole site to static HTML, so there is nothing to run in production and pages load fast.
• Markdown: All content is written in Markdown, so adding or updating a page is just editing a text file.
• PicoCSS: A lightweight, semantic CSS framework. It gives the site a clean, responsive baseline without much custom CSS.
• Lucide Icons: A simple icon set used for section and navigation glyphs.
• YAML Data Files: Hugo reads structured content (resume, skills, certifications, project details) from YAML files in data/, so that content lives in one place and is reused across the site.
• Custom Theme: I customized the theme to match my own branding instead of shipping a stock look.
• GitHub: The site is version-controlled in Git, so every change is tracked and the history is recoverable.

Designing the Website

Planning the Structure

I started by outlining the sections I wanted: Professional Initiatives, Development Projects, About Me, and Contact. The aim was a site that is easy to navigate and puts the work first, with a clear hierarchy that points visitors at the most important content.

Customizing the Design

Using PicoCSS as the base, I adjusted the layout, color, and typography to match my branding and keep the reading experience clean. Lucide handles the section and navigation icons.

Leveraging YAML Data Files

My resume, skills, certifications, and project details live in YAML files under data/, separate from the layout and templates. Updating content means editing data, not markup.

It also keeps things consistent. Update the resume once and the change shows up everywhere that data is used. A small detail, but it saves real time.

Why Not resume.json?

JSON Resume is the obvious standard to reach for: one resume.json, a published schema, and a stack of themes and exporters that already read it. I looked at it and chose a custom YAML structure instead. The reasons are specific to how I actually use this site.

Career progression does not fit a flat work list. JSON Resume models work as one entry per position, each with its own start date, end date, and flat list of highlights. My time at one company runs fourteen years across six titles, from Help Desk Technician to Enterprise Architect. In a flat list that either collapses into a single entry that hides the progression, or fragments into six entries that lose the fact it was one continuous run at one employer. My structure nests it the way it happened: a company with an overview, then a list of roles, each with its own dated bullets.

experience:
  list:
    - company: "Rea Magnet Wire"
      total_time: "2012 to Present"
      overview: "Progressed from frontline help desk to Enterprise Architect..."
      roles:
        - title: "Enterprise Architect"
          dates: "2026 to Present"
          items:
            - details: "..."
        - title: "Help Desk Technician"
          dates: "2012 to 2014"
          items:
            - details: "..."

The skills model carries more than a name and a level. A JSON Resume skill is a name, a coarse level word, and a list of keywords. Mine carries a numeric level_score for the rating bars, years_experience, a last_used year for recency, a primary flag, a type (platform, tool, domain, methodology), a details paragraph, and category grouping with icons and weights. The site renders the rating bars, the experience labels, and the weighted sidebar straight off that data. A keyword array cannot drive any of it without bolting extra metadata on the side.

The data doubles as site configuration. Sections and items carry enable, show_in_sidebar, sidebar_weight, and max_items. I turn a section on or off, or reorder the sidebar, by editing the data, not the templates. JSON Resume is deliberately presentation-agnostic, which is the right call for a portable interchange format, but it means that display logic has to live somewhere else. I would rather keep one source of truth.

Credentials need images and room to explain. My certifications carry a Credly badge image and a full description. The JSON Resume awards and certificates sections are short text records with no image field, so the badge wall on my education page would have nowhere to live in the schema.

The tradeoff is real, and I accept it. My structure is bespoke, so I cannot hand this resume.yaml to a JSON Resume theme or exporter and get a rendered resume back. JSON Resume is built for that portability, and if my goal were a single file any tool could read, I would use it. My goal is a site I control end to end, where the data model fits my history instead of the other way around. For that, a schema I own wins.

Challenges and Lessons Learned

Balancing Simplicity and Functionality

The main tension was keeping the site simple to navigate while still showing some technical depth. PicoCSS handled most of that: a clean default I could extend where I needed to.

Making It Personal

Avoiding a cookie-cutter feel mattered to me, so I wrote the content in my own voice and tuned the design, colors, fonts, and tone, to fit.

Managing Structured Content

The YAML approach paid off but needed planning up front: how the data should be structured, and how it would be used across the site. A good reminder to design for maintainability from the start.

Why This Website Matters

The site is less a static portfolio than a working project I keep changing. I add initiatives and projects as I go, adjust the design, and try new features when it is worth it. It doubles as a live example of the kind of web work I can do end to end: build, host, and maintain.

Final Thoughts

Building it has been useful beyond the result. It gave me a real project to maintain rather than a one-time setup, and it doubles as a working example of the tooling I use. I expect to keep changing it as my work does.