Project Overview

This project is a digital media platform backed by a large internal operations system. The public product gives users access to live broadcasts, on-demand video, lectures, articles, events, FAQs, searchable content, and donation flows. Behind that, the platform also supports the people running it: publishers, moderators, content operators, and admin users who need to manage media, schedule releases, review requests, and keep content moving through the pipeline.

From the codebase, it is clear the product exists to solve more than presentation. It centralizes distribution, publishing, communication, and operational control in one place instead of forcing teams to juggle disconnected tools.

Quick Summary

Project Type: Media platform with custom admin and operational backend
Platform: Web application with public frontend, API layer, and internal admin panel
My Role: Lead + Backend Development
Team Size: N/A
Duration: N/A

Problem

The main challenge was not simply publishing content online. The platform had to support a full operating model around media: organizing large content libraries, managing categories and playlists, handling livestreams, powering donation pages, moderating community interactions, and supporting internal staff workflows such as approvals, follow-up, newsletters, and content publishing.

The existing shape of the system reveals a second challenge: growth over time. There are older web routes, newer API namespaces, a custom admin panel, and two frontend applications that support an updated web experience. That usually means the product had to keep shipping while the architecture evolved. One challenge was clearly how to modernize without breaking the workflows the business already depended on.

Goal

Success here looked like building a platform that could reliably serve end users and internal teams from the same ecosystem. On the public side, that meant fast access to content, search, playback, accounts, and donation journeys. On the internal side, it meant giving operators the tools to publish, review, moderate, transcode, schedule, and follow up on work without relying on manual coordination outside the system.

From an engineering perspective, the goal was to make that complexity manageable through an API-driven architecture, reusable services, scheduled jobs, and admin workflows that matched the way the business actually operated.

My Contribution

I worked on this as the lead and backend developer, so my role sat at the intersection of architecture, implementation, and delivery. I was involved in shaping the backend structure, extending API capabilities for the newer frontend, and supporting business workflows that went well beyond a standard content site.

My contribution was not just about writing endpoints. It included thinking through how media entities should behave across web, admin, and operational contexts; how authentication and gated actions should work; how to support media processing and transcription workflows; and how to expose all of that cleanly enough for the frontend to move faster. I also had to make practical decisions inside a codebase that had clearly evolved over several generations, which meant balancing cleanup with continuity.

Tech Stack

Frontend

Next.js + React Used to build the public-facing web experience with route-based pages for home, live, VOD, lectures, search, articles, events, donations, and authenticated user flows.
Tailwind CSS Used for fast UI composition across a large set of reusable components and responsive layouts.
Axios Used as the client API layer with centralized auth token handling and 401 redirect behavior.
i18next Used because the product supports multilingual and RTL/LTR-aware rendering.
JW Player Used for media playback, which makes sense in a platform centered on video and livestream content.
FullCalendar Used for event-oriented views and scheduling-related user experiences.

Backend

Laravel 12 / PHP 8.3 Used as the core application framework for the admin panel, public web routes, API layer, scheduled tasks, and operational workflows.
Service-layer API design Controllers in the newer API namespace delegate to service classes such as HomeService, VideoService, AuthService, and others. That reflects a conscious push toward keeping controllers thinner and backend logic more reusable.
Sanctum + Passport Both are present, indicating support for token-based authentication across different client surfaces and possibly legacy/mobile compatibility.
MySQL-style relational model The migrations and Eloquent models point to a heavily relational content and workflow data model.

Infrastructure

Laravel scheduler Used for recurring cache refreshes, content synchronization, background checks, and periodic operational tasks.
Queue support Queue configuration is present even though the default is configurable. This reflects awareness of asynchronous workload needs as the platform grows.
FFmpeg + shell scripts Used for transcoding, clipping, audio extraction, and generating multi-quality media outputs.

Integrations

Mailgun Used for newsletter and transactional email flows such as subscription management and password reset.
hCaptcha Used during registration to reduce abuse on public auth flows.
AI chat via Dify Used as a proxy-backed chatbot feature over platform content, with quota controls and allowlisting.
RunPod / Python-based transcription workflow Used for transcription processing, showing an incremental path for AI/media tooling inside the existing system.

Testing

PHPUnit Testing scaffolding is present, but automated coverage is relatively light compared with the operational surface area.

Architecture Notes

The architecture is split into three clear layers:

A public web experience built in Next.js
A Laravel API and legacy/public route layer
A large Laravel admin and operations backend

What I found interesting was that the codebase does not pretend this is a simple greenfield application. It shows signs of real-world evolution: older server-rendered routes coexist with a newer /api/shofarweb/v1 API, and there are two frontend directories that strongly suggest an active redesign or migration path. Rather than being a weakness, that tells the real story of the work. The engineering challenge was to create forward movement without forcing a full rewrite.

On the backend, the newer API layer is organized by domain. That is important because the product domains are broad: videos, lectures, articles, events, donations, FAQs, favorites, auth, search, chat, and contact flows each have their own service and controller structure. This improves maintainability compared with packing all business logic into route handlers.

Scalability is approached pragmatically. I can see caching commands for homepage and category/sidebar data, scheduled jobs for repeated background work, pagination across content-heavy endpoints, and media transcoding moved into scripts rather than blocking user requests. The system also separates public interaction from admin workflows, which is a useful boundary as traffic and editorial activity grow independently.

What I Built

API Layer for the New Web Experience

Purpose
Provide a cleaner backend contract for a newer frontend while preserving the platform's existing content and workflows.

Engineering challenges
The challenge was not just exposing data. The API had to consolidate behavior across videos, lectures, articles, search, comments, likes, favorites, events, donations, and user actions, while still fitting into a codebase with older patterns and legacy routes.

Implementation highlights
The newer namespace uses dedicated controllers and services for each domain. That structure made it easier to add features like comments, likes, favorites, download requests, and authenticated question flows without turning the API into a monolith.

Business value
This created a cleaner path for frontend delivery and made the platform easier to evolve beyond its earlier server-rendered experience.

Media Publishing and Playback Backend

Purpose
Support large-scale content delivery across videos, lectures, playlists, categories, embeds, and related-content experiences.

Engineering challenges
Media platforms rarely have one clean content type. Here, videos and lectures overlap, some content is live-derived, some is clipped, some is categorized deeply, and some needs embeddable playback or download gating.

Implementation highlights
The backend handles category-driven retrieval, related-content logic, multi-surface playback data, chapter retrieval, comment and like support, and special handling for things like dubbed content, shorts, and unioned lecture/video results.

Business value
This made the content library navigable and reusable across homepages, detail pages, playlists, embeds, and search.

Admin Operations System

Purpose
Give internal teams the tools to run the platform rather than treating operations as an afterthought.

Engineering challenges
A system like this accumulates real operational needs: moderation, permissions, scheduling, approval review, newsletters, live control, follow-up tasks, and content management across many entity types.

Implementation highlights
The admin routes cover a wide range of internal systems including videos, lectures, articles, livestreams, banners, newsletters, approvals, user permissions, messaging, follow-up tasks, and donation/campaign management.

Business value
Instead of relying on spreadsheets, inboxes, or ad hoc coordination, the platform brings operational work into the product itself.

Media Processing Pipeline

Purpose
Turn uploaded or source media into publishable, multi-quality assets that the platform can reliably serve.

Engineering challenges
Video operations introduce heavy processing concerns that typical CRUD applications do not have: multiple resolutions, audio extraction, trimming, volume normalization, status tracking, and long-running jobs.

Implementation highlights
The platform includes FFmpeg-based shell workflows for transcoding and audio generation, status updates back into the application, and command/scheduler support for recurring background work.

Business value
This reduced the dependency on manual media preparation and made the publishing pipeline more repeatable.

Transcription and AI-Assisted Features

Purpose
Extend the platform's content utility through transcription and content-aware chat.

Engineering challenges
Adding AI to an existing platform is rarely just an API call. It introduces quotas, gating, source attribution, file handling, and operational concerns around long-running processing.

Implementation highlights
The platform includes a chat proxy with allowlists and daily quotas, plus transcription flows that convert media to audio, invoke external processing, and return structured outputs such as CSV transcripts.

Business value
These features improve discoverability and reuse of the content library while showing a practical path for layering new capabilities onto an established system.

Purpose
Support authenticated user actions without giving up operational oversight.

Engineering challenges
Not every action should be immediate in a platform like this. Some content interactions require moderation or approval, especially when downloads or direct communication are involved.

Implementation highlights
The backend includes authenticated flows for favorites, asking questions, gated download requests, moderation-aware comment handling, and admin review screens for approvals and follow-up.

Business value
This creates a better balance between self-service user experience and internal control.

Key Engineering Challenges

Evolving a Live System Without a Rewrite

One challenge was clearly architectural evolution. The platform shows older web routes, a newer API namespace, and parallel frontend codebases. That usually means the product needed to keep operating while major pieces were modernized. The tradeoff is that you accept some complexity in exchange for continuity and lower migration risk.

Modeling Real Operational Workflows

A lot of systems look simple until you include the people running them. Here, approvals, moderation, newsletters, follow-up tasks, media review, and livestream administration are part of the product. That adds complexity to authorization, state management, and admin UX, but it is also where a lot of product value lives.

Handling Media as a First-Class Backend Concern

This platform has to do more than store references to files. It has to manage transcoding, audio derivation, chapters, playback sources, live states, and publish timing. That changes how you think about background processing, storage, and operational observability.

Balancing Access and Control

Authentication is not limited to sign-in. The platform uses token-based auth, download approvals, admin middleware, superadmin-only flows, and limited-access AI chat. One challenge was making user-facing actions smooth while keeping enough control for internal teams.

Introducing Newer AI Features Into an Existing Product

I found the transcription and AI chat work especially interesting because it shows incremental modernization. Instead of rebuilding the platform around AI, the implementation wraps those capabilities in controls that fit the product: quotas, allowlists, source handling, admin access, and exportable transcript outputs.

Outcome

The end result is a platform that functions as both a media destination and an internal operating system for content teams. It brings together publishing, live content, search, donations, moderated user interactions, approvals, and media operations in a single ecosystem.

I would describe the outcome less as a single feature launch and more as a platform with growing operational maturity. The code shows a product that expanded from content delivery into workflow support, and a backend that had to keep absorbing new requirements without losing its core responsibilities.

Why This Project Matters

This project is important in my portfolio because it shows the kind of work I enjoy most: the point where backend engineering, product thinking, and operational reality all meet. I was not just building isolated endpoints. I was helping shape how content moved through the business, how teams interacted with the system, and how new capabilities could be introduced without destabilizing an already active platform.

It also demonstrates range. There is API design, admin tooling, media processing, auth and permissions, workflow modeling, and third-party integrations all in one codebase. For me, that is a much better representation of engineering ownership than a narrower project with cleaner boundaries but fewer real-world constraints.

What I Learned

This project reinforced how important it is to design for workflow, not just data. A media platform like this is only partly about what end users see. A large part of the value comes from giving internal teams reliable tools to publish, moderate, review, schedule, and follow up on work.

It also taught me a lot about evolving architecture responsibly. In a growing product, you do not always get to start over. Sometimes the better engineering decision is to introduce cleaner service boundaries, newer APIs, and automation around the edges while the business continues to run. I enjoyed working in that space because it requires both technical judgment and a realistic understanding of how software gets maintained over time.

Media Platform Modernization