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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.