Project Overview

This project is a teacher-focused digital portal designed to deliver structured educational content through a web experience backed by a fairly involved operations platform. On the user side, teachers can browse content, search by category, save favorites, view recent activity, manage their profile, complete guided registration steps, and access subscription-based materials. On the internal side, the platform gives administrators tools to manage content, file groupings, user records, subscriptions, packages, promotional sliders, series, and message campaigns.

The reason a product like this exists is operational as much as editorial. Educational organizations often have strong content but weak delivery systems. This platform turns a scattered content library and manual administrative work into a more cohesive product with clearer access rules, more structured onboarding, and a repeatable internal workflow for maintaining the system over time.

Quick Summary

Project Type: Educational content delivery and subscription platform
Platform: Web application with public portal, authenticated teacher experience, and Laravel admin panel
My Role: Lead delivery bridge between client stakeholders and developers; I translated requirements into implementation tasks, reviewed work and code, and owned delivery quality
Team Size: N/A, but clearly built for multi-role collaboration

Problem

The core challenge was operational fragmentation. The product needed to serve teachers through a clean frontend experience, while also giving an internal team the tools to manage content, access rules, subscriptions, and communications without relying on ad hoc manual processes.

In this project, a few concrete problems stand out:

Educational content was not just a flat list of files. It had categories, nested taxonomy, file types, preview assets, access restrictions, featured sections, and relationships to series.
User onboarding required more than a simple signup form. The platform supports a configurable multi-step registration and profile completion flow, reflecting the organization's need for richer teacher data than a standard account system could provide.
Access control depended on subscription type, payment status, and content classification, so entitlement logic had to be enforced consistently.
Internal staff needed an operational console for managing users, subscriptions, exports, campaign messaging, and publishing workflows.

In other words, the challenge was not only building features. It was turning several moving business processes into one maintainable platform.

Goal

Success for this project looks like a platform that can do three things well at the same time:

Give teachers a usable, modern portal for discovering and accessing relevant learning materials.
Give the operations team a reliable backend for managing content, users, subscriptions, and communications.
Reduce manual coordination by encoding business rules directly into the product, especially around onboarding, permissions, publishing, and paid access.

My Contribution

My role here was closer to technical lead and delivery owner than an isolated feature developer. I was the bridge between the client or manager and the development team. That meant I was usually the person receiving requests, clarifying intent, breaking work into tasks, briefing developers, reviewing both implementation and code, and making sure the final result was suitable to deliver back to the client.

What I find valuable about this kind of role is that it forces technical judgment at multiple levels. I had to understand the business request well enough to translate it cleanly, understand the architecture well enough to guide implementation, and understand the code well enough to review quality and catch issues before delivery. The work sat at the intersection of product thinking, systems thinking, and execution.

I would describe my contribution areas as:

translating stakeholder needs into engineering tasks
aligning frontend and backend work against the actual workflow
reviewing implementation details and code quality before delivery
protecting delivery quality across multiple modules instead of only one slice of the system
keeping the team moving while still making sure the output matched the business request

Tech Stack

Frontend

Next.js 15 + React 19
Used for the teacher-facing portal. The app router structure, route-based pages, and client components suggest the team wanted a modern React application with server-friendly routing and a smoother content experience.
Tailwind CSS
Used to move quickly on UI composition across onboarding, catalog, profile, teacher management, and content pages without a heavy custom CSS framework.
Axios
Used as the shared API client with token injection through interceptors, which keeps authenticated requests consistent across the frontend.
Formik + Yup
Present in the frontend stack and aligned with the form-heavy nature of the product, especially around registration and profile completion.

Backend

Laravel 11
Used as both API layer and admin application. This is a strong fit for a product that combines relational data, admin CRUD, background jobs, authentication, and server-rendered internal tools.
Laravel Sanctum
Used for token-based authentication between the frontend app and backend APIs.
Yajra DataTables
Used in the admin layer for operational listing screens such as users and content, where filtering and tabular workflows matter.
Laravel Excel
Used for export and campaign file ingestion, which makes sense for operations teams working from spreadsheets.

Infrastructure

AWS S3-compatible object storage
Used for content file storage, asset handling, and upload flows. The platform includes direct S3 disk usage and pre-signed upload URL generation.
Laravel queue worker + scheduled console commands
Used for background and recurring operations such as campaign sending, subscription charging, and periodic date synchronization.
Laravel Telescope assets and logging signals
These indicate an effort to support debugging, observability, and internal maintenance.

Integrations

Google OAuth
Used for Google-based sign-in support.
Payment gateway integration
Used to charge subscription packages and persist payment and subscription records.
Email service integration
Used for password reset and user communication workflows.
WhatsApp / messaging integration
Used for outbound messaging and template-based campaign sending.

Testing

PHPUnit scaffold
The Laravel test structure is present, but the repository only shows basic example tests. The foundation exists, but the automated test suite is not yet a major strength of the project as committed here.

Architecture Notes

The architecture is interesting because it splits responsibilities in a practical way rather than forcing everything into one interface.

The Next.js app handles the teacher-facing experience: home discovery, catalog navigation, item detail pages, favorites, search, subscription selection, profile management, and guided registration.
The Laravel API exposes the application workflows that power that experience: authentication, item retrieval, search, onboarding form submission, payment, teacher management, and metadata.
The Laravel web/admin layer handles internal operations: user management, content administration, packages, file categories, sliders, series, and messaging campaigns.

That separation makes sense. The public-facing experience benefits from a dedicated frontend, while the operations team gets a server-side admin workflow that is efficient to maintain.

A few maintainability decisions stand out:

Service-layer organization in Laravel keeps controllers relatively thin and pushes business logic into dedicated services like ItemService, HomeService, AuthService, TeachersService, and UserFormService.
Dynamic user-form modeling through steps, categories, fields, and permissions makes onboarding configurable without hardcoding every profile question into the frontend.
Relational content modeling supports categories, series, file types, subscription types, tags, publish checklists, and usage tracking.
Optional authentication middleware allows the platform to serve both anonymous and logged-in experiences from the same endpoints, which is useful for progressive access patterns.

From a scalability perspective, the system is clearly designed to grow in breadth. It already supports multiple content groupings, multiple subscription types, scheduled processing, admin search, exports, and campaign operations. The bigger long-term challenge would be keeping business rules coherent as more workflows accumulate.

What I Built

1. Teacher Experience Platform

Purpose
Create a usable frontend for teachers to browse educational resources, search content, save favorites, review recent activity, and manage their account.

Engineering challenges
The frontend had to support both anonymous browsing and authenticated personalization while staying aligned with the backend's access rules. It also had to present different content sections such as featured, hot, new, recent, and user-preference-driven items.

Implementation highlights
The Next.js app is organized around route-based experiences such as home, catalog, item detail, search, favorites, profile, premium access, series, and registration. The API client injects auth tokens consistently, and the home experience pulls together category navigation, sliders, and personalized content sections.

Business value
This turns a raw content library into an actual product experience for teachers, which is a very different proposition from simply hosting files online.

2. Dynamic Registration and Profile Completion System

Purpose
Capture richer teacher information through a guided, multi-step workflow rather than a shallow signup form.

Engineering challenges
The challenge here is flexibility. Once onboarding requirements grow, hardcoded forms become expensive to maintain. The system needed validation, step progression, conditional visibility by user type, and storage of structured responses.

Implementation highlights
The backend models registration as steps, categories, fields, and per-user-type permissions. The frontend consumes a wizard-style structure and validates step-by-step before final submission. The same model also supports profile completion and preference updates.

Business value
This gives the organization a better understanding of its users and supports more tailored experiences, especially around content relevance and internal workflows.

3. Subscription and Access Control Layer

Purpose
Support both free and paid access models while tying entitlement rules directly to content availability.

Engineering challenges
Subscription logic is rarely isolated. It influences payment flow, account state, content visibility, file access, and admin reporting. The code supports multiple subscription types and package structures, which adds complexity.

Implementation highlights
The system tracks packages, subscription types, subscription periods, payments, renewals, and active subscriptions. Content access is checked against subscription relationships, and payment success creates persistent subscription and payment records. There is also logic for free plan initialization and scheduled charging.

Business value
This turns the platform into a sustainable delivery model instead of a purely open repository of materials.

4. Content and Media Management Backend

Purpose
Enable internal teams to manage educational items, categories, files, statuses, series, and publishing workflows.

Engineering challenges
The content model is deeper than a basic CMS. Items can belong to nested categories, carry tags, have multiple files, support previews, belong to series, and be gated by subscription type. Admin users also need filtering and visibility into publishing state.

Implementation highlights
Laravel admin controllers and views cover item CRUD, category ordering, file category management, series assignment, publish checklists, and upload handling through cloud storage. The item model includes relationships for categories, files, main file, tags, series, and subscription types.

Business value
This is what makes the platform operable. Without a robust admin layer, the frontend experience would become stale and hard to maintain.

5. Teacher Account Management for Parent Accounts

Purpose
Allow one authenticated user to manage associated teacher accounts inside the same platform.

Engineering challenges
This introduces hierarchical user relationships, ownership checks, and a mini-management workflow inside the product itself.

Implementation highlights
The API exposes create, list, update, view, and delete operations for teacher records linked through parent_id. The frontend includes a dedicated management screen and modal workflow for maintaining these associated records.

Business value
This shows the platform is designed for real organizational use, not only single-user self-service.

6. Campaign and Messaging Operations

Purpose
Support outbound communications through templated messaging workflows tied to imported spreadsheets and scheduled jobs.

Engineering challenges
Operational messaging needs more than a send button. It requires file ingestion, template parameter mapping, failure handling, scheduled processing, and auditability.

Implementation highlights
The platform includes WhatsApp template management, Excel file analysis, campaign persistence, per-recipient campaign messages, and a scheduled command that processes pending campaigns every five minutes.

Business value
This reduces manual outreach effort for the operations team and integrates communication into the platform rather than handling it externally.

7. Personalized Discovery Logic

Purpose
Make the home experience more relevant than a generic content feed.

Engineering challenges
Relevance is not only a ranking problem here. The system has to consider category eligibility, date-driven content, user preferences captured during onboarding, watched history, and access constraints.

Implementation highlights
HomeService assembles multiple curated sections including newest, hot, last seen, user preference items, and date-sensitive content. What I found especially interesting is the inclusion of calendar-driven logic and category matching based on user registration data.

Business value
A more relevant home experience helps users discover content faster and makes the platform feel purposeful instead of overwhelming.

Key Engineering Challenges

Workflow complexity across multiple audiences

The product serves at least two very different audiences: teachers and internal operators. That creates tension between a smooth public experience and a robust back-office workflow. The architecture solves this by separating the modern frontend from the operational Laravel admin surface.

Dynamic onboarding and profile data

One challenge was handling complex user data without locking the team into brittle frontend forms. The form-step-category-field model is a practical solution because it moves a lot of structure into configurable data.

Access control tied to business rules

Paid access is not just a billing concern here. It affects item visibility, file downloads, previews, and user state. The tradeoff is that access checks become spread across multiple parts of the system, so service-layer consistency matters a lot.

Content modeling beyond simple CRUD

Items, files, categories, tags, series, checklists, and subscription mappings all interact. That makes the data model powerful, but it also raises the cost of careless changes. Strong model relationships and admin tooling help keep that complexity manageable.

Operational messaging and scheduled processing

Campaign messaging introduces asynchronous work, external dependencies, and delivery state tracking. The use of scheduled commands and persisted campaign message records shows the system was built with repeatable operations in mind rather than one-off scripts.

File handling and media delivery

Cloud file storage, previews, zip generation, and controlled file access all create edge cases around performance, access, and cleanup. The code reflects that this was an important part of the product, not an afterthought.

Outcome

Based on the repository, the platform became a fairly complete operational product rather than a narrow web app. It unified:

teacher onboarding
content discovery
gated file access
subscription purchase and account state
internal content administration
user management
campaign messaging workflows

I am deliberately not claiming metrics because the repository does not provide them. What can be said with confidence is that the system centralizes several previously separate concerns into one product with both external and internal interfaces.

Why This Project Matters

This project matters to me because it reflects the kind of work I enjoy most: the space where engineering decisions are inseparable from delivery judgment and product understanding.

I was not just looking at one isolated feature. I had to understand what the client wanted, translate that into work the developers could execute, review the implementation with enough depth to protect quality, and then deliver something that made sense as a business tool. That combination of technical review, architecture awareness, and stakeholder alignment is a big part of how I like to operate.

From a portfolio perspective, this project shows breadth. It covers frontend product experience, API design, admin operations, payments, dynamic forms, access control, cloud storage, and scheduled integrations. It also shows ownership in the less glamorous but more senior sense: making sure the whole thing holds together.

What I Learned

This project reinforced how quickly complexity grows once a product moves beyond "just build a portal." The moment you add onboarding depth, subscription logic, content governance, internal tooling, and communications, you are no longer building pages. You are designing an operating system for a team.

What I found interesting was how much leverage came from structure. The dynamic form system, service-layer organization, and dedicated admin workflows all point in the same direction: if you encode the business process well, delivery gets easier and the product becomes more resilient.

It also reminded me that leadership in engineering is often about translation. A lot of the value is not only in writing code. It is in making sure the right thing gets built, the implementation is reviewed properly, and the final delivery is something both the team and the client can trust.

Systems Engineering Case Study