Md Foysal Ahmed
EdTech SaaS2026

CCApply

A multi-portal study abroad platform for students, agents, institutions, and admins with applications, documents, offers, commissions, invoices, reports, and real-time chat.

Next.jsTypeScriptReactNestJSMySQLTypeORMTailwind CSSShadcn UITanStack QueryReact Hook FormZodSocket.IORecharts
CCApply screenshot 1
CCApply screenshot 2

Project Overview

CCApply is a full-stack study abroad management platform built for Creative Consultancy. It connects students, education agents, universities, and internal administrators in one operational system for discovering institutions, comparing programs, submitting applications, managing documents, tracking offer letters, processing visas, handling commissions, and communicating through live chat.

The platform includes a public-facing website for discovery and a set of role-specific dashboards for daily operations. Students can search programs and apply directly, agents can manage student pipelines and commission records, institutions can maintain campuses and programs, and admins can control the complete education consultancy workflow from a centralized panel.

Key Features


Technologies Used

Frontend

TechnologyPurpose
Next.js 16App Router, route groups, SSR, metadata, and routing
React 19Component-driven dashboard and public interfaces
TypeScriptStrong typing across UI, forms, hooks, and API layers
Tailwind CSS v4Responsive styling and reusable design tokens
shadcn/ui + Radix UIAccessible UI primitives for dashboards and forms
TanStack QueryServer state, caching, mutations, and invalidation
TanStack TableSearchable and paginated data tables
React Hook Form + ZodValidated forms for profile, signup, and apply flows
Socket.IO ClientReal-time chat communication
RechartsDashboard charts and reporting visuals
ZustandLightweight client-side state management

Backend & Infrastructure

TechnologyPurpose
NestJS 11Modular REST API architecture
MySQL 8Relational database for operational education data
TypeORMEntity modeling, repositories, and database access
JWT + PassportAuthentication and protected API access
RBAC GuardsRole and permission based authorization
Socket.IOWebSocket gateway for live chat
MulterDocument, avatar, logo, and media upload handling
NodemailerEmail verification and password reset flows
SwaggerAPI documentation for backend endpoints
Docker ComposeLocal API and MySQL development environment

Platform Modules

Public Website

The public website is designed for prospective students exploring study abroad options. It includes country and institution mega menus, university/program discovery, reviews, services, resources, contact pages, and a homepage with banners, counters, top institutions, program highlights, and a floating video widget.

Student Portal

Students can create accounts, complete their profile, add education history and test scores, upload documents, search institutions and programs, apply to a program, track applications, review offer letters, follow visa processing, save favourites, and communicate through chat.

Agent Portal

Agents can register agencies, manage students, create applications on behalf of students, upload documents, track applications and offer letters, view commission reports, generate invoices, manage staff access, and follow up through operational reports.

University Portal

Universities can maintain their institution profile, create and edit campuses, manage programs, review applications, track students, maintain representative profiles, manage staff users, and review performance reports.

Admin Portal

Admins control the whole platform. The admin panel includes metrics for institutions, programs, students, applications, and agents; CRUD management for universities and programs; application review; offer letter tracking; visa processing; leads; followups; staff roles; system settings; text reviews; public content; and finance workflows.


Architecture Highlights

Multi-Role Route Structure

The frontend separates the product into public and protected route groups:

app/(public)      -> public website and discovery pages
app/student       -> student auth and dashboard
app/agent         -> agent auth and dashboard
app/university    -> institution auth and dashboard
app/admin         -> admin auth and protected operations

This keeps each portal focused while still sharing common hooks, API utilities, layout components, and design primitives.

Modular NestJS Backend

The API is split by domain modules instead of one large controller layer:

auth, users, student, agent, university, admin,
application, finance, search, chat, staff,
notifications, media, visa-process, audit-log

Each module owns its controller, service, DTOs, and related entities, which makes the platform easier to extend as new consultancy workflows are added.

Relational Data Model

The MySQL schema models real consultancy relationships:

Permission-Aware APIs

Protected routes use JWT authentication and role guards so each user type only sees the records they should access. Shared application endpoints include visibility checks, while admin endpoints expose broader system-wide controls.


Challenges Faced

1. Supporting Four Different User Journeys

Problem: Students, agents, universities, and admins all needed separate dashboards, but their workflows overlap around the same data: students, applications, documents, programs, and offer letters.

Solution: Built dedicated portal route groups and backend modules while sharing core application, search, document, and communication services. This allowed each role to get a tailored interface without duplicating the central business logic.

2. Complex Application Lifecycle

Problem: A study abroad application moves through many states: profile completion, document collection, submission, review, offer, acceptance, rejection, visa processing, and finance tracking.

Solution: Modeled application stages, status history, offer letters, documents, and visa processes as first-class entities. Admins can update status and stage, while students, agents, and universities see role-appropriate application detail screens.

3. Finance and Commission Management

Problem: Agents need transparent commission tracking, while admins need control over commission rules, approval, invoice generation, and payment status.

Solution: Added finance modules for commission models, commissions, invoices, invoice items, approval states, invoice history, and analytics pages. The backend exposes separate admin and agent finance endpoints so each side has the correct level of control.

4. Large Operational Dashboard Surface

Problem: The platform has many dense operational screens, including tables, filters, forms, charts, documents, staff roles, settings, and reports.

Solution: Standardized the frontend around reusable dashboard layouts, data-table patterns, form validation, query caching, toast feedback, and component primitives. This reduced UI inconsistency and made new modules faster to build.


Results


Links


Built with Next.js, NestJS, MySQL, TypeORM, Socket.IO, Tailwind CSS, and shadcn/ui.