This portfolio has a fairly small job: turn Markdown, templates and assets into pages that a browser can read. Keeping that build easy to understand matters more to me than introducing a larger application framework.

The site uses Hugo Extended, a pinned PaperModX theme, custom CSS and a small amount of JavaScript. Vercel serves the generated output. The CMS edits the same Markdown files in GitHub, so a content change goes through the normal deployment path.

Make the environment explicit

The production command is:

1

hugo --gc --minify --environment production

A preview needs a different environment because its search-indexing policy is different:

1

hugo --gc --minify --environment preview --destination public-preview

In this site’s deployment configuration, Vercel’s environment is passed through to Hugo. Production pages can be indexed; preview pages emit noindex. That is a site-template decision, not something the word “preview” magically guarantees in Hugo.

Know what a timing includes

The time Hugo reports for rendering is only one part of a deployment. Downloading the build tool, fetching the theme, preparing assets and uploading output can take longer than generating the HTML.

If a deployment becomes slow, I would measure those stages separately before changing the renderer. A cached build-tool download solves a different problem from an expensive template loop.

Pinning the Hugo version and theme revision also makes a surprising change easier to investigate. Otherwise, a content-only commit can pick up a new dependency and quietly become a software update.

Inspect the output

A successful process exit means the build completed. It does not tell you that a résumé link exists, a draft stayed unpublished or the canonical URL points to the right host.

For this site, those are useful checks on the generated files. They exercise the result someone will actually receive, and they keep the deployment contract small enough to understand when something breaks.

Reference: Hugo command options.