ShowHub is a fullstack TV show organizer that replaces rigid, one-size-fits-all trackers with a genuinely personalised system you design yourself — built solo in four weeks as a 3rd semester project and a real solution to a real problem

ShowHub is a TV show tracking and community platform. It gives users a central place to manage their watching habits — not just a checklist, but a system with custom lists, episode-level progress tracking, written reviews, and per-show discussion forums. Data for every show, episode, and cast member is pulled live from the TVMaze public API.

This was my 3rd semester project, and at the same time a solution to a problem I actually had. I was watching shows across different platforms and keeping mental notes about where I was, what I thought about episodes, and what I wanted to watch next. There was no single place that let me track all of that the way I wanted to organise it. Existing tools either locked you into their structure or didn't go deep enough on customisation.

This case study covers how I designed and built ShowHub solo over four weeks — the API research process, the schema design that took almost a full week on its own, the technical decisions, what I shipped, and the things I'd do differently now that I've been on the other side of it.

Note: ShowHub is currently in prototype phase. Core functionality is working and has been manually tested across all major modules, but there's no automated test coverage, and further hardening and optimisation is still needed.

There was no good way to track TV shows in a structure you actually designed yourself — most trackers are rigid, shallow, and built around their categories, not yours

The core problem: Most trackers force you into their pre-defined categories — watched, watching, plan to watch — and offer little beyond that. You can't attach detailed notes to entries, track season and episode progress at a granular level, or organise shows across multiple custom lists the way you'd naturally think about them.

The sub-problems that made this harder to solve:

• Fragmented data sources — show data lives across many scattered APIs; finding a reliable, free, and accessible one was a challenge that had to be solved before a single line of UI code could be written
• A non-trivial data model — the list and entry schema has to accommodate default lists, custom lists, per-entry ratings, episode progress, notes, start/finish dates, and visibility settings — all in a schema that stays sane as features get added
• A 4-week learning constraint — the timeline ran simultaneously with learning the entire MERN stack, meaning every architectural decision had direct time consequences

The person affected was me — and anyone who watches a meaningful amount of TV and wants more than a bare-bones checkbox tracker. The expectation is a tool that's as flexible as a spreadsheet but designed specifically for this purpose.

The primary goal was simple and specific: let a user sign up, build personal show lists, and control every detail of every entry — ratings, notes, progress, and visibility

Primary goal: Enable a user to sign up, log in, and manage their personal show lists — with full control over ratings, notes, episode/season progress, and list visibility.

My definition of done, as it existed before I started:

• ✓ Users can register and authenticate securely
• ✓ Users can search for any show and view its full details
• ✓ Users can add shows to lists and track episode/season progress per entry
• ✓ Lists are editable: ratings, notes, start/finish dates, visibility per list and per entry
• ✓ Default lists — Plan to Watch, Watching, Completed — are pre-created per user
• ✓ Custom lists can be created and managed
• ✓ User profiles are searchable and public lists are viewable by others

Everything beyond the above was treated as a stretch goal — nice-to-have, but not required for the project to be considered done:

• Reviews with a rich text editor, like/dislike interactions, and privacy controls
• Show-specific forums with threaded replies and rich text support
• Top-rated episodes display, cast listings, and external show links

All stretch goals were shipped. The primary definition of done was cleared completely.

The stack was chosen deliberately for learning, not for optimal technical fit — MERN was the target, and this project was the vehicle to actually understand it as a system

Frontend

• React.js — component-based UI across all feature areas
• React-Quill — rich text editor used for reviews and forum posts

Backend

• Node.js — runtime environment
• Express.js — API routing and middleware layer

Database & Auth

• MongoDB — document database; embedded document model used for list entry data
• JWT (JSON Web Token) — stateless authentication across all protected routes

External Data

• TVMaze Public API — source of all show metadata, episode details, cast information, and ratings; requires no API key or authentication

Each layer was a first for me at the time. This wasn't a project where I applied a known stack — it was the project where I learned the stack by building something real with it.

Before writing any code, the biggest open question was the data source — and the path to TVMaze was a process of elimination that nearly ran out of time

The most significant pre-build research was finding a viable API for show data. Without a reliable data source, the project had no foundation.

API Evaluation

Three options were considered:

• IMDb API — either paid or required an approval process I couldn't complete in time; ruled out immediately
• TMDB (The Movie Database) — free and well-documented, but their onboarding was broken at the time of my application; multiple requests, no approval; time was running out
• TVMaze Public API — required zero authentication, no approval process, no API key setup, just open endpoints; turned out to have one of the most comprehensive TV-specific databases available — covering network TV, OTT originals, anime, and local/international shows

TVMaze was the most practical choice given the circumstances, and it ended up being a genuinely good one — not a compromise, just a different path to the same destination.

Other Research

Beyond the API search, research was limited and intentional. I chose the MERN stack because I wanted to learn it — there was no comparative evaluation between frameworks. The decision was deliberate: this project was explicitly a MERN learning exercise, and going with something familiar would have defeated that purpose.

React-Quill was picked for the rich text editor without evaluating alternatives. It was the most commonly referenced React-compatible Quill wrapper at the time, covered all required formatting features, and worked for what I needed.

Planning was minimal but intentional — I started with a mental map of core entities and their relationships, and the list schema alone took close to a week to get right

Planning before coding skipped wireframes and component trees entirely. The starting point was a mental model of the core entities and how they related to each other — the key question being: what are the main objects in this system, and how do they connect?

The answer drove everything: User, Show (external, from TVMaze), List, ListEntry, Review, Forum, ForumPost, Reply. The relationships between these — especially between a User, their Lists, and the individual entries within those lists — were where the real architectural complexity lived.

The List Schema Problem

The list/entry schema was the single hardest design problem in the project. It took close to a week of thinking and revision to arrive at a structure that could support:

• Default lists vs. custom lists
• Per-entry ratings, episode and season progress, notes, start/finish dates
• Individual entry visibility — independent of the parent list's visibility
• Integration with external show data from an API I didn't control

The schema had to be flexible enough to accommodate new fields without constant breaking changes, but structured enough to be queryable and maintainable. MongoDB's embedded document model was the right fit here — per-entry metadata made sense as nested documents rather than a fully normalised relational structure.

Lesson learned mid-project: Because the schema kept evolving as I discovered new feature requirements during frontend work, I spent significant time going back to add, remove, and restructure fields. Features that were half-built had to be revised. This was the defining struggle of the build — and the most lasting lesson: don't start the frontend until the data model is stable.

Component architecture wasn't formally planned. I built and organised as I went, which led to a messy structure by the end — a problem I now address upfront on every project.

The ideation phase was focused almost entirely on the data architecture — the product concept was clear from day one, but how to model the list data took real exploration before it clicked

Given the 4-week timeline and the fact that I was learning MERN while building, there was no formal ideation phase with multiple design directions to compare. The overall product concept was clear from day one — a personalised show tracker — and the energy went into figuring out how to build it rather than what to build.

Schema Exploration

The one area where I actively explored options was the list data architecture. Several approaches were considered before landing on the final structure:

• Flat list model — simple, but couldn't carry per-entry metadata without becoming unwieldy
• Fully relational approach — more normalised, but MongoDB's document model made this awkward and query-heavy
• Embedded document model — entries as nested documents within list documents; allowed rich per-entry data without JOIN-equivalent queries

The deciding factor was which model let me store and query the most per-entry detail without the schema becoming unmanageable. The embedded approach won.

Feature Prioritisation

On the feature side, I drew a clear line between what was necessary (the list management core) and what was additional (reviews, forums, cast display). That separation meant I could commit to the foundation first and add social and content features after the core was solid — which is exactly how the build played out.

Every major technical decision in ShowHub was driven by either a learning goal, a hard time constraint, or a data modelling trade-off — here's what was chosen and why

Stack Choice

Chosen: MERN — MongoDB, Express, React, Node

This was a deliberate learning project. MERN was chosen because I wanted to learn it, not because it was the optimal technical fit for the problem. The constraint was intentional — this was the whole point of the project.

External Data Source

Chosen: TVMaze Public API
Considered: IMDb API, TMDB

IMDb was inaccessible within the timeline. TMDB's onboarding was broken at the time. TVMaze required no auth, had comprehensive TV data, and was the only option that unblocked the project under the time constraint.

Authentication

Chosen: JWT (JSON Web Token)

Stateless, widely documented for MERN projects, and appropriate for a single-developer prototype. No need for session infrastructure or a third-party auth service at this stage.

Rich Text Editing

Chosen: React-Quill
Alternatives evaluated: None

Most commonly referenced React/Quill integration at the time. Covered all required formatting features — headings, media embeds, code blocks — without needing to evaluate further.

List Entry Data Model

Chosen: MongoDB documents with embedded entry metadata

Per-entry data — rating, progress, notes, dates, visibility — was complex enough to warrant embedded documents in Mongo rather than a fully relational structure. Suited the document model and avoided unnecessary JOIN-equivalent queries.

Each of these decisions was made under real constraints, not ideal conditions. In most cases the constraint was the rationale.

ShowHub shipped as a fullstack web app covering auth, show search, personalised list management, rich-text reviews, threaded forums, and user profiles — everything scoped, everything delivered

TL;DR: A fullstack web app where users sign up, search for TV shows via the TVMaze API, manage personal show lists with episode-level detail, write rich-text reviews, and discuss episodes in show-specific forums.

Core Modules Delivered

Auth System Secure signup/login with JWT-based authentication and protected routes across the app.

Show Search & Detail Full show search with detailed pages: poster, banner, metadata, episode breakdowns, cast, top-rated episodes, and external reference links — all sourced from TVMaze.

Lists & Entry Management Three default lists per user — Plan to Watch, Watching, Completed — plus unlimited custom lists. Per entry: rating, episode/season progress, notes, start and finish dates, and independent visibility controls.

Visibility Controls Lists and individual entries can be set public or private, independently. Fine-grained control over exactly what others can see.

Reviews Per-show rich-text reviews using React-Quill — headings, blockquotes, code blocks, embedded media. Like/dislike interactions and public/private privacy settings per review.

Forums Show-specific discussion boards with categories, threaded replies at any depth, and React-Quill formatting. Forums created from a show's detail page carry a non-removable show tag automatically. Users can add custom tags alongside it.

User Profiles & Search Searchable user profiles. Public lists and public reviews from any user are visible on their profile.

Responsive UI The interface is fully responsive, built with React across all feature areas.

The solution addresses the core problem by replacing a rigid tracker with something built around the user's own organisation style — you control the lists, the names, the detail level per entry, and what's visible to others.

The final shipped product covers seven distinct modules — each one annotated here with the technical or design detail worth calling out

Auth Pages

Login and signup with form validation and JWT-protected sessions. Authenticated state persists across the app. Basic client-side validation is applied to both forms before submission.

Show Search

Search any TV show and receive results pulled live from the TVMaze API. Because TVMaze requires no authentication, this works immediately — no API key management on the client side, no token refresh logic, no auth headers.

Show Detail Page

Each show has a dedicated detail page surfacing:

• Poster and banner image
• Ratings, episode count, premiered and end dates, summary
• Full season and episode breakdowns with per-episode detail
• Top-rated episodes
• Full cast listing
• External reference links

The notable technical detail here is the integration boundary — show data from TVMaze is fetched on demand, but user-specific data (list membership, reviews) lives in MongoDB and is joined at the application layer.

Lists & Entry Management

The most complex module in the app. Three default lists are auto-created on user registration. Users can:

• Create additional custom lists
• Add any show to any list
• Edit each entry individually — rating, episode/season progress, freeform notes, start and finish dates
• Toggle visibility independently at the list level and the entry level
• Remove shows from any list

Both lists and individual entries carry independent public/private visibility — a private entry inside a public list stays hidden.

Reviews

Per-show reviews written with the React-Quill rich text editor. Full formatting support:

• Headings, blockquotes, code blocks
• Embedded images and video links

Other users can like or dislike reviews. Like and dislike are mutually exclusive — toggling one removes the other. Reviews can be set private to hide them from public view.

Forums

Show-specific discussion boards organised by category. Forums created from a show's detail page receive a non-removable show tag automatically — users cannot delete it. Users can add extra custom tags alongside it. Threaded replies work at any depth. Forum posts use the React-Quill editor with full formatting support: headings, italic, strikethrough, images, videos, and links.

User Profiles

Searchable user profiles. Public lists and public reviews from any user are visible on their profile page. Private content is always filtered from public views.

All testing was manual and functional — no automated framework, but every major module was verified against its specified behaviour, including edge cases and permission boundaries

There's no automated test suite — this was a prototype built under a tight deadline, and writing tests was out of scope. What I did instead was manual functional testing across every major module after the build was complete, verifying that core behaviours worked as specified. Edge cases like empty states, optional fields, and permission boundaries were specifically targeted.

Lists — Core Behaviour

• ✓ Users can add shows to all three default lists: Plan to Watch, Watching, Completed
• ✓ Moving a show between default lists removes it from the original — no duplicate entries in defaults
• ✓ A show in a default list can still be added to a custom list — mutual exclusivity applies only between the three defaults
• ✓ Users can create custom lists and add shows to them
• ✓ Private lists are hidden from other users; only the owner sees them
• ✓ Private entries remain hidden even inside a public list — entry-level visibility is enforced independently
• ✓ Users can remove shows from any list, default or custom

Lists — Entry Editing

• ✓ Rating can be edited per entry and intentionally left empty — the field is optional
• ✓ Episode/season progress can be modified and left empty
• ✓ Start and finish dates are independently editable and can both be left blank
• ✓ Visibility can be toggled independently at the entry level and the list level
• ✓ Shows can be deleted from any list through the entry edit interface

Reviews

• ✓ Summary enforces a character range: under 20 or over 120 characters are rejected on submission
• ✓ Review body enforces a 2200-character minimum — submissions under the threshold are blocked
• ✓ Rich text formatting renders correctly: bold, italic, headings, lists, embedded images, and video links
• ✓ Private reviews are not visible to other users — only the author sees them
• ✓ Like and dislike are mutually exclusive — selecting one deselects the other; a user cannot hold both simultaneously
• ✓ Clicking the same reaction again undoes it — likes and dislikes are togglable, not one-way

Forums

• ✓ Thread nesting works at any depth — replies to replies render the correct hierarchy
• ✓ Like/dislike on forum posts behaves identically to reviews: mutually exclusive and togglable
• ✓ Forums created from a show's detail page automatically receive a non-removable show name tag
• ✓ Rich text formatting works in forum posts: headings, italic, strikethrough, images, videos, links
• ✓ Users can add custom tags when creating a thread, in addition to the auto-applied show tag

Form Validation

• ✓ Login and signup forms validate required fields and surface errors before submission — empty or malformed inputs are caught client-side
• ✓ Basic validation is applied consistently across other forms: list creation, entry editing, forum creation

All tests confirmed passing. The absence of automated coverage is acknowledged and is on the v2 improvement list.

The hardest part wasn't any single feature — it was the list schema, which cost nearly a week and kept breaking everything downstream every time it changed

The Hardest Problem

The list and entry schema. It took close to a week — roughly a quarter of the entire project timeline — to arrive at a data model that could handle all the requirements without falling apart as features were added. The challenge wasn't any single concept; it was the compounding complexity of designing a schema that served multiple overlapping needs simultaneously:

• Default vs. custom lists
• Per-entry metadata at multiple levels of granularity
• Visibility controls at both list and entry level
• Integration with external show data from an API I didn't own or control

Every time I thought the schema was done, a new frontend requirement would expose a gap — and I'd have to revise it, often causing cascading changes across the API layer and UI that was already built against the old shape.

What Didn't Get Finished

The following were scope cuts under time pressure — not skill gaps:

• Folder structure refactor — the codebase is functional but disorganised
• Pagination across list views, search results, and forum threads
• Expanded social features and full user profile editing

They're all on the v2 list.

Unexpected Wall

Working with third-party API data I couldn't modify or cache properly. Structuring the boundary between TVMaze data and my own MongoDB data — knowing what to store locally vs. what to fetch on demand — took more thought than expected, and the current implementation may not be optimal.

What I Actually Learned

ShowHub was where I actually learned MERN — not just the syntax, but the way the layers fit together as a system. How a React component talks to an Express route, how that route queries MongoDB, how auth middleware intercepts that request, how a JWT carries identity through the stack. I understood each piece individually before this project. This is where they clicked together.

The biggest process insight: the data model is the foundation, not something you figure out as you go. When the schema is stable, everything flows. When it isn't, you're constantly rebuilding on shifting ground.

On the UI/UX side — design decisions and data architecture decisions aren't separate. The way you design a list entry view directly determines what fields the schema needs. They have to be designed together, or at minimum with awareness of each other.

Of the goals set before the project started, all primary criteria were met and every stretch goal shipped — the 10–15% gap is in code quality and completeness, not in features

Revisiting each goal from the original definition of done:

• ✓ Secure signup and login with JWT auth
• ✓ Show search and full detail pages via TVMaze
• ✓ Add shows to lists and track episode/season progress per entry
• ✓ Editable list entries: ratings, notes, dates, visibility
• ✓ Default and custom list management
• ✓ User search and public profile/list viewing
• ✓ Reviews, forums, and all stretch goals shipped
• ✗ Code quality and organisation — functional but messy; folder structure needs a full refactor

Overall fulfillment: roughly 85–90%. Everything in the definition of done was shipped. What's missing is quality and completeness in areas like pagination, social features, and code organisation — things I knew were unfinished but ran out of time to address. The features exist; the craft around them needs work.

The v2 roadmap starts with a full codebase refactor before anything new gets added — then pagination, social features, and deeper personalisation

Planned — v2

• Folder structure refactor — the current codebase isn't organised; this is the first fix before adding anything new
• Pagination across list views, search results, and forum threads
• Expanded social features — follows, activity feeds, social interactions beyond likes on reviews
• Full user profile editing — avatars, bios, display preferences

Longer-term

• More granular personalisation — custom list fields, personal rating scales, watch habit analytics
• Notification system for forum replies and new episodes of tracked shows
• Performance improvements: caching TVMaze responses, optimising MongoDB queries, reducing unnecessary re-fetches
• Automated testing suite — unit and integration tests; manual functional testing has been completed across all major modules, but there's no test framework or automated coverage yet

The refactor comes first. Everything else built on top of a messy codebase just makes the debt worse.

Looking back with what I know now, three things would change immediately: schema before Frontend, Clear Requirements, and documentation from day one

Technical Architecture

Lock down all entity schemas before writing a single frontend component. The back-and-forth between schema design and frontend implementation was the most expensive mistake in this project. I'd also plan the component and folder structure upfront — not because I had a preference for one system at the time, but because any intentional structure is better than no structure, and you pay the debt of the latter for the rest of the project. I now understand the value of feature-based organisation; I'd implement it from day one.

Requirements First

Keep requirements as clear and as concrete as possible before touching the schema or writing any feature code. The recurring pain in this project — schema revisions, half-built features that had to be reworked, API routes that needed changing mid-build — traced back to requirements that were vague or undiscovered at the start. When you don't know exactly what a feature needs to do, you can't design the data model that supports it. Concrete requirements aren't bureaucracy — they're the thing that stops you from building the same feature twice.

Planning & Process

I'd document from day one — not for the case study, but for myself during the build. The absence of documentation meant I couldn't clearly articulate what I'd built during the project presentation, and it limited what I could reflect on here. Even brief notes on why a decision was made, or a quick before/after when something changed, would have been enormously useful. Lazy documentation is a tax you pay at the end when it's too late to recover the details.

These aren't a list of failures — they're evidence that the project worked. I came in not knowing MERN, system design, or how UI and architecture decisions intersect. I left with a working fullstack app and a specific, hard-won understanding of what I'd do differently. That's the point of building something real.