git init (How This Started)
I have been in engineering leadership long enough to know the pattern. A senior engineer mentions a tool in standup — Flyway, Snyk, Lambda — and while the manager may know what it does in the abstract, they have never actually used it. Like soup-to-nuts installed, configured, tested, broke and fixed again. They may nod along and ask reasonable questions, but cannot have the conversation that matters: the one that leads to understanding the tradeoffs, the parts that are harder than expected, and the decisions they almost made differently.
And of course by "they" above, I mean me. And that gap bothered me more than I let on.
So on New Year's Day 2026, I was resolved to learn something new. I opened a GitHub repo and started resurrecting a website I helped co-found back in 2005 (hdtvmagazine.com). It was dated, like most tech-focused sites are, but peaked near a million monthly visits and ran for about seven or eight years. The codebase was PHP 5, the server was MySQL-something-old, and it had just enough moving parts to be a great candidate for a variety of cloud services. Perfect.
Fifteen weeks later, I had rebuilt it into something I would not be embarrassed to show an architect. Still simple compared to most enterprise-grade cloud architectures, but all the building blocks were in place and I'm confident it could scale if it needed to.
git log (The Build, Phase by Phase)
I had a full backlog in my head before I even had the source code unpacked. I churned for a minute trying to figure out where to start and then decided to just dive in. Here's the short version of the arc, recreated from my commit history (there's a post coming about that too):
Phase 1 (Jan 1-18): Unpacking the source code and setting up the repo (GitHub). Setting up the local dev environment (Docker). Getting LAMP installed and serving pages. Install error handling (Whoops). Replace deprecated database calls, wire in Composer, stand up GitHub Actions, EC2, CodeDeploy, store secrets in SSM Parameter Store from day one. First deploy in the first week.
Phase 2 (Jan 19 - Feb 14): Introduce a static site generator — a TypeScript/Node tool that reads from MySQL and emits static HTML — and layer it into the existing PHP app via Apache rewrites. CSS overhaul toward a token-based design system.
Phase 3 (Feb 15-28): Flyway for database schema versioning. First AWS AI integration: a batch inference pipeline using AWS Bedrock to generate article excerpts at scale across 4,000 pieces of legacy content.
Phase 4 (Mar 1-14): The biggest infrastructure month. Migrated 11,830 forum topics and 28,553 posts from phpBB into a proper community database. Algolia for search. RDS replaces local MySQL as the production database. Flyway migrations move into the CodeBuild pipeline.
Phase 5 (Mar 15-31): Three major pieces in two weeks. An equipment data pipeline using AWS Lambda and the Best Buy API, moving data through raw/silver/gold layers with transform logic in SQL stored procedures. Clerk replaces phpBB for authentication. URL health observability via Apache access logs, S3 archiving, Lambda parsing, and Slack alerting.
Phase 6 (Apr 4-6): The DevSecOps sprint begins. Dependabot across all ecosystems. SonarCloud baseline — surfaced SQL injection in 8 files and XSS across 10+ files, all remediated same-day. CodeQL, then Semgrep as the PHP/JS SAST blocking gate.
Phase 7 (Apr 9-12): Checkov for IaC scanning. Snyk for dependency CVEs. All tool outputs land in S3 and surface in a unified admin findings dashboard. PHPUnit bootstrapped. AWS Security Hub. Cloudflare handling edge TLS in Full/Strict mode.
Phase 8 (Apr 13-15): PHPUnit and integration tests wired to real Flyway-migrated test databases in CI. Qodana (JetBrains PHP linter) onboarded with a cloud-stored baseline, gated on zero new findings above baseline.
git blame (Why Was This Done)
I want to be honest about the motivation because I think it matters for how you read the rest of this series.
This was not a portfolio project. I was not trying to prove I could still code. I am an engineering manager who spends most of his time on the strategic vs the tactical, and I am comfortable with that. What I was not comfortable with was leading teams through technical decisions for which I had no hands-on context. I kept hearing tool names in standups and sprint reviews and feeling like I was operating one level removed from the actual work. I didn't just want to nod and move along — I wanted to know enough to ask the smart questions, get the team thinking, and make sure my team had what they needed to deliver.
The certification path helps, but certifications without hands-on are just vocabulary tests. You need reps.
HDTV Magazine was the right project because it was mine, the subject matter genuinely interested me, and the stakes were low enough that I could make real mistakes. I replaced Clerk twice. I onboarded CodeQL and then immediately superseded it with Semgrep. I built things I later decided were overkill. And I found myself chasing my tail trying to fix findings that didn't really matter. These are exactly the issues my teams encounter, the decisions they need to be able to make, and I understand them better now because I made them myself.
And it has to be said — AI made this possible in a real way. The lift on a project like this — legacy codebase, unfamiliar tools, no team — would have been prohibitive a few years ago. And honestly it's probably a big reason why I finally decided to start it. Claude Code handled a lot of the scaffolding and research that would have eaten weeks. I still made every architectural decision and wrote a meaningful amount of the code, but AI is the ultimate force multiplier when you know how to use it — and that compressed the learning curve significantly.
git push (What's Next)
Each phase of this build gets its own post. Some of them are straightforward technical write-ups, but a few of them will go somewhere unexpected. The DevSecOps sprint in particular produced some genuinely interesting findings — two SAST tools scanning the same codebase with zero overlap, a silent security gap in AWS CodeDeploy, and SonarCloud's PHP blind spot with template expressions.
If you are an engineering leader who has been meaning to get hands-on with the tools your teams are using, I hope this series gives you a useful on-ramp. You do not need a greenfield project, you just need something you are willing to break.