Portfolio & Career Content System

01 / Challenge

The delivery problem.

Career facts had to remain consistent across a public website, browser resume, concise application resume, and detailed technical resume without duplicating content or weakening presentation quality.

Who needed it: Recruiters and engineering reviewers exploring my work, and me as the maintainer of several resume formats.

02 / Approach

What I personally built.

1. 01

   Designed a schema-validated career record consumed by every presentation channel.

2. 02

   Rebuilt the portfolio on the official Untitled UI React and Vite stack, preserving static pages, content validation, and resume downloads.

3. 03

   Generated separate PDF and DOCX formats from the same factual source while preserving channel-appropriate layout.

4. 04

   Added strict diagnostics, static production builds, subpath packaging checks, and explicit deployment configuration.

03 / Outcome

What changed.

Established one maintainable publishing workflow for the portfolio and resume library while keeping web, PDF, and Word presentations aligned.

• Designed one structured content architecture for every career presentation channel.
• Redesigned the website with free Untitled UI React components while preserving static content and accessible navigation.
• Added strict diagnostics, static production builds, subpath packaging checks, and explicit deployment configuration.
• Prepared separate PDF and DOCX presentation contracts without duplicating career facts.

04 / Systems & decisions

APIs, data, and infrastructure.

One career.json record supplies React pages, project routes, and resume content. A dependency-free schema check validates required fields before publishing.

React and free Untitled UI components render through Vite at build time. Browser hydration adds search and filtering; core content and links are in the generated HTML.

Python produces PDF and Word resumes. Vite packages static assets for Cloudflare; a separate build verifies the /portfolio/ GitHub Pages base path. There is no runtime API or database.

Constraints and tradeoffs

• Static rendering keeps content available before JavaScript runs and avoids a service/database to operate. Career changes require a rebuild.
• One factual record reduces content drift. Web and print use separate layouts because native documents cannot run React components.
• Cloudflare and GitHub Pages need different asset bases. Both builds are checked; configuration alone does not prove a production deployment.

05 / Evidence

What you can inspect.

How this supports my FDE direction

This is a publicly inspectable example of owning data contracts, interface composition, document generation, and deployment packaging. API integration experience is documented in the career case studies.

06 / Toolkit

Tools in context.

07 / Implementation walkthrough

Follow one content change through the system.

1. 01

   Start with data

   Edit the public career record in src/content/career.json. Required fields and unique project slugs are checked before a build.

2. 02

   Render the interface

   React composes the record with free Untitled UI controls. Browse the work page or follow a project link; static HTML keeps the case studies readable without JavaScript.

3. 03

   Generate documents

   pnpm resume:generate creates the resume formats from the same record, with Inter and the website’s blue theme tokens.

4. 04

   Validate and package

   pnpm verify checks types, content, production output, and GitHub Pages paths. pnpm build:cloudflare restores the root-path build.

5. 05

   Deploy explicitly

   wrangler.jsonc points Cloudflare Static Assets at dist. Deployment is a separate release action; this walkthrough does not claim the current branch is live.

This implementation connects a UI, structured data, generated documents, and deployment packaging. It has no runtime API; the career case studies describe my API and environment integration work.