PHP
The engine room. Routing, business logic, rendering, and everything powering the admin side of the application.
EVERY EPISODE STARTS WITH A QUERY
RODFLIX
Browse shows, seasons, and episodes through a simple interface while the database quietly does the heavy lifting behind the scenes.
01The brief
MISSION ACCEPTED
BUILD A CATALOGUE
WITH A DATABASE
AND CONSEQUENCES.
The brief sounded simple enough: build a TV series catalogue backed by a relational database, complete with intuitive navigation and an admin area for managing content.
The "simple" part lasted about five minutes. Soon there were schemas to design, CRUD operations to build, and plenty of opportunities for users to do things I hadn't anticipated.
Looking back, RodFlix wasn't really about TV series. It was about understanding how databases, business logic, and UI work together to create software that feels simple to use.
06
Core technologies
04
Main user flows
01
Very judgmental database
THE OPENING SCENE
Search, filter, browse, then forget why you opened the site.
02Under the bonnet
Pragmatic beats unnecessarily clever
THE STACK
BEHIND THE
STREAM.
Rather than chasing the latest framework, I focused on solid fundamentals: clear responsibilities, relational data, server-side rendering, and an architecture that could grow without becoming difficult to maintain.
SQL
A relational database built around shows, seasons, and episodes connected without relying on crossed fingers.
TVmaze API
Populating the catalogue with real-world data, because manually entering hundreds of TV series sounded like a terrible idea.
HTML, CSS, JS
The part users actually see, designed to stay clean, responsive, and out of the way of the content.
03Feature guide
FOUR REASONS
IT'S MORE THAN
A PRETTY GRID.
Scroll for the full season.
Swipe cards to explore
04Plot complications
EVERY BUILD NEEDS
A LITTLE DRAMA.
WHAT BROKE / 01
A database with too many opinions
Series, seasons, episodes, and related information needed to work together without turning every query into a small tragedy.
WHAT CHANGED / 01
Give every relationship a proper job
The solution wasn't more tables. It was giving each relationship a clear responsibility, making the whole catalogue easier to extend and maintain.
WHAT BROKE / 02
A busy back end, pretending to be simple
Users shouldn't have to think about everything happening behind the scenes. The interface needed to stay simple, even when the application wasn't.
WHAT CHANGED / 02
Keep the user facing the right direction
Predictable layouts, reusable patterns, and clear navigation meant users always knew where they were, without accidentally becoming part of the catalogue themselves.
05What survived production
THE BIT WHERE
I ACTUALLY
LEARNED THINGS.
This was the project where server-side development stopped being a tutorial and started feeling real. Small mistakes had immediate consequences, and fixing them meant understanding the problem rather than searching for another code snippet.
-
01
THE DATABASE ALWAYS WINS
Relational databases became something I could design and reason about, not just query. -
02
FUTURE ME DESERVES BETTER
Keeping the back end and front end readable requires structure, not optimism. -
03
USERS ARE CREATIVE
Input validation isn't a nice extra. It's self-defence.
06Screening room
FIVE SCREENS.
ONE RABBIT HOLE.
0105
The main catalogue
Where browsing begins and productivity quietly ends.
The full picture
Everything worth knowing before deciding whether to invest the next three weekends.
Season deep dive
Every season broken into episodes, because rabbit holes are easier to navigate when they're organised.
Catalogue control
Managing the catalogue without opening phpMyAdmin every five minutes.
Import from TVmaze
Because manually typing every series would be a terrible hobby.
END CREDITS
BUILT END TO END.