Because how it's made matters.
This site is part portfolio, part playground, and 100% me. For better or worse.
I built it to show how I think through structure, design, functionality, and the choices that tie them together. It’s not just a summary of my skills, it’s a living example of them. Every decision, from the stack to the deployment flow, was mine. No templates, no outsourcing, no shortcuts.
This page pulls back the curtain and walks through what’s under the hood and why it’s there. If you’re here to see how I build, you’re exactly where you should be.
Quick Look
This site is built on Drupal 10 and hosted on AWS Lightsail, with Cloudflare handling CDN and DNS for performance and reliability. The domain runs through Porkbun, and the codebase lives on GitHub, with GitHub Actions powering a streamlined DevOps workflow. On merge, actions authenticate with Lightsail via SSH, rsync the updated codebase (excluding critical config and content files), and then use Composer to rebuild dependencies and Drush to run post-deploy tasks like cache clearing and DB updates.
6
Platforms integrated
167
total lines of JS
6
automated GH actions
∞
ideas to come
The Details
- Database: MySQL 8.0.41, hosted locally on the Lightsail instance
- Web Server: Apache via Lightsail’s LAMP stack
- CMS: Drupal 10Layout Builder, custom Twig templates, and preprocess logic
- Server Resources: 1 GB RAM, 2 vCPUs, 40 GB SSD
- Dev Tools: Lando + Docker for local, Git/GitHub for VCS, VSCode as primary IDE
The Stack
A lot of thought went into how I wanted to build this. The goal was to balance speed to market with hands on control and the opportunity to demonstrate my skills & thought process.
Infrastructure
I considered Acquia for its CI/CD pipeline and robust DevOps tooling (Pipelines, Site Factory), but opted for AWS Lightsail to maximize control, cost-efficiency, and self-hosted responsibility. Lightsail gave me full root access and SSH capabilities while abstracting away EC2’s heavier network config overhead.
Version Control
As a longtime Github user, I gave thought to switching to GitLab to expand the skillset, but sometimes it just feels good to stick with old faithful.
Work flow
The selection of GitHub allowed me to utilize GitHub Actions to automate my merge process and code deploys. Triggered on merges into my main branch, GitHub Actions connects to my Lightsail instance via SSH using stored secrets and executes a multi-step workflow:
- File Syncing – It uses rsync to copy updated files while excluding the /files directory, settings.php, and settings.local.php to preserve environment-specific configurations and content.
- Dependency Management – It runs composer install --no-dev --optimize-autoloader to regenerate the vendor directory since /core and /vendor are excluded from the repo.
- Post-Deploy Operations – It executes drush cache:rebuild to clear caches and trigger configuration changes, and clears the Cloudflare CDN cache via API for end-to-end freshness.
This mirrors real-world CI/CD practices and simplifies troubleshooting and rollback by tagging each release per merge.
CMS
I went with Drupal given my near decade of experience with it, but also for the flexibility it offers to build and grow my skillset moving forward. The site is built on Drupal 10, using Composer-based scaffolding (Drupal/recommended-project) to cleanly separate core, contrib, and custom codebases.
Layout Builder is the foundation of page structure, providing flexibility in visual configuration without compromising maintainability. I’ve extended it with custom Twig templates and theme preprocessing to create reusable components that maintain accessibility, SEO integrity, and styling consistency.
The custom theme follows Drupal best practices with strict PSR-12 adherence, and is fully sustainable and deployable across environments. I’ve also implemented key contrib modules like Pathauto, Metatag, Webform, and Schema Metatag to support scalable content modeling, search optimization, and API readiness.
In the future, I plan to use Drupal’s built-in REST and JSON:API capabilities to power a headless front end—likely built in React—while maintaining the core CMS foundation.
Analytics & SEO
Every site needs a strong analytics foundation—otherwise how will I know if anyone besides my dad is visiting?
This site uses:
Google Tag Manager to deploy tags, including a standard GA4 implementation.
Microsoft Clarity for heatmaps, session replays, and deeper interaction insights.
SEMRush to validate crawlability, technical SEO benchmarks, and monitor organic visibility.
I also plan to enhance semantic structure with Schema.org metadata, semantic HTML5 tags, and ARIA patterns to support both SEO and accessibility goals.
THE TECH
Rocking with the best in the business.
FAQs
Why did I do this?
I wanted a real-world platform to showcase my capabilities, not just tell people what I can do, but show them. This site also gives me the freedom to experiment with technologies I find interesting, test new workflows, and keep evolving my skillset. And hey, it gave me something productive to build that wasn’t a pitch deck.
Why did I make some of my decisions?
Even though this site is smaller in scale than most of the enterprise platforms I’ve led, the decision-making process was surprisingly similar. It came down to a few key questions:
- What do I need it to do?
- What will I need it to do in the future?
- How can I balance both without overcomplicating the present?
It’s always a trade-off between features and timeline. For example, I built a GitHub Action that can perform DB backups, but chose not to enable it right away. Launching without it removed variables and simplified initial troubleshooting. Once I validate the core pipeline, I’ll layer in those enhancements.
How did I come up with the color palette?
Simple, I used Coolors.co to build the palette, sampling colors directly from a photo of Saquon Barkley’s reverse hurdle play. Kelly green from the jersey, silver from the pants, and black from the Jags helmet. A little fandom, a little flair...color theory with a personal twist.
What's next?
You'll be shocked to hear that an engineer has a thousand ideas for their site. Near-term, I’d like to tap into Drupal’s REST and JSON APIs to prototype a React front end. I also have an idea for a sports game inspired by one I used to play while camping outside Fenway for tickets. (Yes, I just dated myself.)
Longer term, I’ll add form functionality to replace the basic mailto link and build out lightweight e-commerce for the challenge of it. Not because this site needs a cart, but because it’s a muscle I haven’t flexed in a while.
Like what you've heard? I'm happy to connect and talk.
Shoot me an email: [email protected]