Project overview

The purpose

AndrewHakes.com began as a personal-brand website intended to support my professional job search while creating a long-term home for portfolio evidence, technical writing, research, experiments, and personal project development.

The site needed to do more than display a résumé and contact information. It needed to become a platform through which completed learning, demonstrated mastery, technical artifacts, and developing bodies of work could be presented clearly and consistently.

The central requirement was control: one coherent website, reusable presentation patterns, predictable navigation, and a publishing process that could expand without requiring a redesign for every new artifact.

Requirements

What the platform needed to support

  • A professional personal-brand presentation
  • Individual portfolio case studies
  • Technical and reflective blog articles
  • Downloadable supporting artifacts
  • Research and experimental work
  • Personal writing and creative-project development
  • Consistent navigation and visual treatment
  • Reusable page structures
  • A publishing process that could later be automated
  • Flexibility for future author, publishing, project, and creative-business sites
Phase 1

Initial custom PHP site

The project began as a hand-developed PHP website using Bootstrap and a custom stylesheet. This provided direct control over the page structure, navigation, visual hierarchy, responsive behavior, and relationship between content and presentation.

The initial public structure included a homepage, portfolio page, About page, contact page, and the first reusable card and section patterns.

This phase established a clean professional front end, but the site did not yet have a mature or repeatable publishing workflow.

Phase 2

Palette and component testing lab

Alongside the initial website, I built a palette-testing tool that loads JSON color definitions and applies them to Bootstrap-based interface components.

The tool allowed double-complementary and other brand palettes to be evaluated across practical interface elements rather than as isolated color swatches.

Buttons, cards, navigation, headings, alerts, surfaces, borders, shadows, and contrast relationships could be viewed together as a functioning visual system.

This became an early design-system experiment and helped establish the later separation between reusable page structure and replaceable visual identity.

Phase 3

WordPress publishing experiment

After a pause in development, I returned to the site with a narrower immediate requirement: I wanted a straightforward method for publishing writing.

WordPress appeared to offer a quick publishing layer, so I attempted to integrate it with the existing custom PHP front end.

The intended architecture divided responsibilities. The custom site would control the professional presentation, while WordPress would manage article publishing.

In practice, the integration did not remain a small publishing addition. Over several days, routing, theme behavior, editor assumptions, stylesheet interactions, security components, and competing page structures consumed the project.

The resulting system still did not meet the required standard for consistency, control, flexibility, or maintainability.

Phase 4

Removing WordPress and simplifying the architecture

I reevaluated the WordPress integration against the original requirements rather than treating the time already invested as a reason to preserve the decision.

Continuing would have required maintaining two adjacent systems with different routing, styling, editing, and maintenance assumptions.

I removed the WordPress installation and returned the site to one controlled PHP architecture.

Architectural lesson

A platform that is quick to install is not necessarily inexpensive to control. Integration effort, maintenance, visual inconsistency, and future constraints are part of the actual cost of a system.

Phase 5

Unified PHP rebuild

The website was rebuilt around shared PHP components so that all public pages use the same document frame, navigation, styling, and footer.

Shared includes now own the page head, global navigation, footer, Bootstrap assets, favicon references, palette loading, and other site-wide responsibilities.

Each page supplies only its own metadata and content. This reduces duplicated markup and prevents global elements from drifting independently between pages.

  • Shared head.php
  • Shared header.php
  • Shared footer.php
  • Page-specific title and description variables
  • Root-relative navigation
  • Consistent active-page states
  • Reusable Bootstrap and custom CSS patterns

This established the public site as one coherent system rather than a collection of individually maintained pages.

Design system

Separating structure from visual identity

Reusable layout and component behavior were consolidated into the primary site stylesheet, while brand colors were moved into separate palette files.

Structural CSS defines how navigation, cards, articles, buttons, content wrappers, and page sections behave. Palette files define the visual identity without changing the page architecture.

This separation provides a foundation for reusing the same structural machinery across future author, publishing, project, and pseudonym-specific websites without forcing them to share one visual identity.

Phase 6

Reusable publishing templates

The current development phase is converting individual pages into predictable, repeatable publishing patterns.

Blog posts and portfolio projects use shared templates with stable metadata, breadcrumbs, content wrappers, related links, supporting evidence, and navigation.

The immediate production target is three to four presentable artifacts each week.

These artifacts are intended to provide visible evidence of continued learning and applied work in areas such as AI, Godot, systems analysis, technical documentation, web architecture, writing, music, and visual art.

The first version remains deliberately manual so the real publishing process can determine which fields and tools are genuinely needed.

Current architecture

A lightweight publishing platform

/public_html/
    index.php
    about.php
    contact.php
    portfolio.php

    /includes/
        head.php
        header.php
        footer.php

    /css/
        sitestyle.css

        /palettes/
            palette-name.css

    /portfolio/
        /project-slug/
            index.php

    /blog/
        /article-slug/
            index.php

    /templates/
        /portfolio-piece/
            index.php

        /blog-post/
            index.php

    /assets/
        /icons/
        /images/

    /downloads/

Shared machinery remains centralized while each project and article receives a focused page and stable public URL.

Current outcome

A baseline for presenting provable work

The current result is a functioning personal-brand website with shared navigation, reusable visual components, individual portfolio-page support, a lightweight blog structure, and a controlled path for expansion.

More importantly, the site provides a platform for presenting completed learning and demonstrated mastery through case studies, technical articles, project evidence, documentation, and downloadable artifacts.

The architecture supports immediate professional goals while also establishing reusable machinery for future writing, publishing, game-development, art, music, and other creative business projects.

Future development

Utilities built around proven workflows

Future development will focus on small utilities that automate established publishing tasks rather than recreating a general-purpose content-management system.

  • Blog-post creation utility
  • Portfolio-project creation utility
  • Evidence and artifact management
  • Blog-to-portfolio cross-link management
  • Index maintenance
  • SEO and metadata refinement
  • Social-preview metadata support
  • Reusable publishing structures for related sites

The long-term objective is a production platform that supports multiple creative and publishing efforts while reducing the repetitive work required to present each new result.

Professional takeaway

Designing around the actual requirements

This project demonstrates more than front-end implementation. It includes requirements analysis, interface prototyping, platform evaluation, architectural judgment, visual-system development, and publishing-process design.

One of the most important decisions was recognizing when the chosen publishing platform had become a constraint and simplifying the architecture before that mismatch became permanent technical debt.

The resulting system reflects the way I approach technical work: identify the real purpose, expose competing assumptions, establish reusable structure, test the process with real content, and automate only after the underlying workflow is understood.