Case Study · last updated November 2026

The DJ Calendar

Search is becoming answers. When someone asks an AI where their favorite DJ plays next, the sites that get cited aren't the ones that gamed keywords - they're the ones built to be read by machines. The DJ Calendar is my answer to that shift: a solo-built electronic-music discovery platform - tour dates, tour predictions, setlists, show alerts and a newsletter - serving roughly 1,000 pages from a shared cPanel server, no frameworks, no shell access, with a machine-readable layer (validated JSON-LD on every page, llms.txt/ai.txt, agent-facing JSON exports) engineered so Google and ChatGPT can both cite it with confidence.

2015Founded

~1,000Pages live

99/100DJ Mag Top 100 tracked

99Artists in the DB

What it is

thedjcalendar.com answers one question really well: where is my favorite DJ playing next? Around that spine it has grown a whole discovery layer:

Tour dates & artist pages - 99 of the DJ Mag Top 100 tracked with synced event data, audio previews, socials, and per-artist iCal feeds
Tour predictions - a model that forecasts where unsigned artists are likely to play next, with a public scoreboard that grades the predictions as dates pass (first grades land December 1)
Setlists, showdowns & favorites - editorial layers on top of the raw calendar, plus member features: hearts, alerts, near-me geolocation
The newsletter - double opt-in, PDO-backed, with the "Fun Coupons" subscriber perk

The origin story

This started in 2015 as a spreadsheet. I wanted to know where specific DJs were playing without checking twenty different venue sites, so I did what developers do: built a list. Then a scraper. Then pages. Then a database.

The 2026 version is the serious rebuild - the spreadsheet's grandchildren. Over this year I rebuilt it as a proper platform: a custom PHP/MySQL stack, event feeds normalized from Bandsintown and Ticketmaster into one row shape, 99 DJ Mag Top 100 artists tracked across hundreds of cities, and a full SEO/structured-data layer that took the site from hundreds of rich-result warnings to zero.

So: ten years from spreadsheet to platform, with the modern engine built solo across 2026 - design, backend, data pipeline, front end, SEO, ops, and content, all one person.

How it's built

The constraint that shapes everything: it runs on shared cPanel hosting. No shell, no SSH, no deploy pipeline, no background workers. Every architectural choice bends around that reality:

PHP 8 + MySQL (PDO) - the core stack, no framework Vanilla JavaScript - zero JS dependencies, zero build step Apache + .htaccess - routing, caching rules, rewrites schema.org JSON-LD - every page, validated in CI Bandsintown + Ticketmaster feeds - normalized, deduped, cached guarded deploy workers - self-verifying PHP patches (open source) lazy-cron - scheduled jobs with zero crontab (open source)

A few decisions I keep making on purpose:

Zero dependencies is a feature, not an absence. The front end is hand-tuned vanilla JS: hover-audio preview cards with a real Web Audio EQ, client-side search over a prebuilt JSON index, a geolocation tour map that behaves when you say no. Nothing to install means nothing to break.
Structured data is load-bearing. Every page ships validated JSON-LD (Event, MusicGroup, ProfilePage); a custom audit CLI gates regressions. That layer is why the site earns rich results and stays legible to AI crawlers.
Deploys survive without a pipeline. Changes ship as token-gated PHP workers that back up, count their needles, verify byte-exact, auto-restore on failure, and delete themselves. It's open source: guarded-deploy-workers.
Scheduled jobs run without cron. The prediction scoreboard snapshots on first visit after a window opens, claimed atomically through MySQL row locks: lazy-cron.
Performance is measured, then fixed. Homepage LCP went 7.0s → 2.3s (render-chain surgery + self-hosted WOFF2 across the file set), with cache-busted live verification at every step.

The 2026 build log, in one glance

Early 2026 - full rebuild kicks off: data pipeline, artist pages, genre architecture

Spring - schema layer completes: JSON-LD on all ~1,000 pages, zero rich-result warnings

October - the ops month: LCP 7.0→2.3s, tour history, deploy-worker pattern matures, prediction engine ships

November - newsletter + Fun Coupons, public playground, RSS, case studies - and the first tools extracted for open source

What's next

On the board: a PWA with push alerts for tracked artists, affiliate ticket links, and the first prediction scoreboard grades land December 1.

Visit the site Read the engineering stories

Want this kind of engineering on your team?

One person built, shipped and operates everything above. I’m available for full-time and freelance web engineering roles — NYC metro or remote.

Book a 15-min call Email me Résumé (PDF)

bryanhamilton.info · case studies · writing · playground