Personal Resume / Portfolio Site

A resume site is not a Word CV pasted onto the web. Its reader has 30 seconds.

Three sections, fixed order:

1. Who I am: one-line positioning + years + city + current status (employed / available / open to offers)
2. What I've built: 3–5 projects, each written as "context → what I did → result (with numbers)"
3. How to reach me: email plus one backup channel, with a stated response time

How to write a work card:
project (dates) → one-line context → the part you owned → a quantified result
No numbers? Write scale instead — users, duration, role. "Responsible for related work" says nothing.

Leave out: the full employment timeline, course grades, hobbies unrelated to the job. The reader doesn't care, and they dilute the point.

Privacy: no phone number, no home address, no ID numbers. Use a dedicated email address, not your work one.

A resume site needs no framework: one HTML file and one stylesheet is enough — and it solves PDF export along the way.

Structure (a single file is fine):

<header>Name · Positioning · Contact</header>
<section id="works">Work / project cards</section>
<section id="stack">Skill keywords</section>
<footer>Last updated · Download PDF</footer>

The ten lines of print CSS that matter:

@media print {
  .no-print { display: none; }      /* hide buttons and nav */
  a[href^="http"]::after { content: " (" attr(href) ")"; font-size: 12px; }
  body { font-size: 12pt; }
  .card { break-inside: avoid; }     /* cards don't split across pages */
}

Ctrl+P → Save as PDF gives you a cleanly typeset resume, more controllable than any online converter.

Mobile: stack the work cards in a single column, and make contact details tappable with tel: / mailto:.

Dark mode is optional; print styles are not — what the recruiter wants in the end is a PDF.

Domain priority: name.com > name.me > name.dev > a subdomain. Short, spellable, and something you can say out loud — resume links get passed on verbally.

Hosting, pick one:

• GitHub Pages / Vercel: free, automatic HTTPS, push to update
• Object storage static hosting: fast regional access, a few dollars a month
• A subdirectory on a server you already run: cheapest if you have one

Visit tracking (the most overlooked and most useful part of a resume site):
Send pv plus two events:

• contact_click: someone clicks your email or social links — your real conversion
• pdf_download: someone downloads the PDF

Why bother: if you applied to 20 places and only 3 people opened your email, the problem is the channel, not the content. If opens are high but nobody writes, then it is the content. Without data you're only guessing.

Register the definition: put contact_click into data/conversion.json and mark it as the primary conversion event.

While you're there: add canonical, and set description to "name · field · city" so people can find you by search.

What kills a resume site isn't the copy, it's dead links: you change jobs or email, the old URL 404s, and every application that used it is wasted.

Three rules:

1. Update quarterly: even without a job change, add one recent thing and put "last updated YYYY-MM" at the top. An undated resume makes people wonder whether you're still active
2. Links stay valid forever: enable auto-renew on the domain; if you move hosts, 301 the old address instead of deleting it
3. Keep versions: before big edits save resume-YYYYMM.html, so you can tweak the positioning line and reorder work cards per application

How to use it when applying: one main version plus variants tuned per role converts better than one generic resume.

One thing to skip: don't add the resume page to data/index-observation.json — a resume site doesn't need search traffic. What matters is contact_click, not indexing. Being indexed is irrelevant; someone clicking your email is the whole point.