ORIC MUET — Startup & Incubatee Dashboard

A full-stack web platform built for the Office of Research, Innovation & Commercialization (ORIC), Mehran University of Engineering and Technology (MUET), to digitize the startup incubation lifecycle — from student application and faculty review to investor discovery and real-time deal-room communication.

The system connects three stakeholders on one platform:

• Students — submit and manage startup applications, track review status, and receive investor interest.
• Investors — browse ORIC-approved startups, send connection requests, and chat directly with founders once a request is accepted.
• Faculty/ORIC Admins — (role scaffolded) oversee and moderate the incubation pipeline.

---

Table of Contents

• Features
• Tech Stack
• Project Architecture
• Data Models
• Application Flow
• Getting Started
• Environment Variables
• Route Reference
• Real-Time Chat (Socket.IO)
• Validation & Security
• Project Structure
• Roadmap
• Author

---

Features

🔐 Authentication & Role Management

• JWT-based authentication stored in httpOnly cookies (no client-side token exposure).
• Role-based access control for student, investor, and faculty accounts.
• Password hashing with bcrypt; server-side validation via Joi.
• Session-aware post-login redirect — users are returned to the page they originally requested (redirectURL pattern).

🎓 Student / Startup Owner Portal

• Register a startup application (title, abstract, description, incubation level: idea / prototype / business model).
• Edit or withdraw applications while status is pending (locked once approved/rejected).
• Personal dashboard with application count, latest submission, and recent investor interest.
• View and respond to incoming investor connection requests.

💼 Investor Portal

• Dedicated investor dashboard with request analytics (total, pending, accepted).
• Browse a curated list of ORIC-approved startups only.
• Send one-time connection requests to startups (duplicate requests are blocked).
• Track sent requests and their status (pending / accepted / rejected).

🤝 Connection Request Workflow

• Investor → Startup connection requests with a pending → accepted/rejected state machine.
• Only the startup owner can accept/reject a request targeting their startup.
• An accepted request unlocks a private real-time chat room between the investor and the founder.

💬 Real-Time Investor–Startup Chat

• Powered by Socket.IO, authenticated via the same JWT cookie used for HTTP routes.
• Chat rooms are scoped per connectionRequest._id — only the investor and the startup owner tied to that request can join.
• Messages are persisted in MongoDB (sender, role, name, timestamp) and replayed on room join.

📝 Feedback System

• Any authenticated user can submit categorized feedback (bug, suggestion, complaint, general).
• Users can view their own feedback history.

---

Tech Stack

Layer	Technology
Runtime	Node.js
Web Framework	Express.js 5
Templating	EJS
Database	MongoDB with Mongoose ODM
Real-Time Engine	Socket.IO
Auth	JSON Web Tokens (JWT) + httpOnly cookies
Password Security	bcrypt
Validation	Joi
Session/Flash	express-session, connect-flash
Middleware Utils	cookie-parser, method-override, cors, dotenv

---

Project Architecture

The application follows a classic MVC pattern with a clean separation of concerns:

Routes  →  Controllers  →  Models  →  MongoDB
   ↓            ↓
Middleware   Views (EJS)

• index.js — application entry point; wires up Express, session/cookie middleware, the HTTP server, and the Socket.IO server, and mounts all route modules.
• routes/ — thin route definitions, each mapped to a controller method and wrapped in auth/validation middleware.
• controllers/ — business logic for each domain (auth, students, investors, startups, connection requests, chat, feedback).
• models/ — Mongoose schemas defining the data contracts.
• validations/ — Joi schemas enforcing input integrity before it reaches controllers.
• middlewares.js — shared middleware: isloggedin (JWT guard), WapAsync (async error wrapper), and per-entity Joi validators.
• views/ — server-rendered EJS templates, organized by role (Investor/, startupApplication/).

---

Data Models

User

Field	Type	Notes
fullName, email, username, password	String	Core identity fields; email & username are unique
role	Enum	student, faculty, investor
companyName, orgEmail, location, website	String	Investor-only profile fields

Startup

Field	Type	Notes
title, abstract (≤250 chars), description	String	Application content
level	Enum	idea, prototype, businessModel
status	Enum	pending (default), approved, rejected
submittedBy	ObjectId → User	Owning student

ConnectionRequest

Field	Type	Notes
investor	ObjectId → User	Requesting investor
startup	ObjectId → Startup	Target startup
connectionStatus	Enum	pending (default), accepted, rejected

Message

Field	Type	Notes
connectionRequest	ObjectId → ConnectionRequest	Scopes the chat room
sender	ObjectId (dynamic ref via senderModel)	Author of the message
senderModel, senderName, senderRole	String	Denormalized for fast rendering
text	String	Message body
read	Boolean	Read-receipt flag (default false)

Feedback

Field	Type	Notes
feedbackBy	ObjectId → User	Author
category	Enum	bug, suggestion, complaint, general
feedbackDescription	String	Body

---

Application Flow

1. Registration — a new user picks a role (student/investor/faculty) on the generalized signup form; role-conditional fields (e.g. investor company info) are validated by Joi (UserJoi.js).
2. Login — credentials are verified with bcrypt; a signed JWT (7-day expiry) is issued as an httpOnly cookie and the user is redirected to their role-specific dashboard.
3. Startup submission — students submit incubation applications, which enter the system with status: pending.
4. Discovery — investors only ever see startups with status: approved in the Browse Startups view.
5. Connection request — an investor sends a request to a startup they're interested in; duplicate requests to the same startup are blocked.
6. Acceptance — only the startup's owner can accept or reject the request. Acceptance flips connectionStatus to accepted.
7. Live chat — once accepted, both parties can join a Socket.IO room keyed by the connectionRequest._id, exchange messages, and have full history persisted and replayed.
8. Feedback loop — any logged-in user can log platform feedback for ORIC to review.

---

Getting Started

Prerequisites

• Node.js (v18+ recommended)
• MongoDB running locally (or a connection string to a hosted instance)

Installation

# Clone or extract the project
cd "ORIC Task"

# Install dependencies
npm install

# Configure environment variables (see below)
cp .env.example .env   # then fill in real values

# Start the server
node index.js

Route Reference

Auth (/)

Method	Route	Description
GET	/	Renders the general registration form
POST	/register	Creates a new user (role-aware validation)
GET	/login	Renders the login form
POST	/login	Authenticates a user, issues JWT cookie
POST	/logout	Clears the auth cookie

Student (/) — requires login

Method	Route	Description
GET	/dashboard	Student overview: applications, recent investor requests
GET	/myApplications	List of the student's submitted startups
GET	/investorconnections	Connection requests received on the student's startups

Startup (/) — requires login

Method	Route	Description
GET	/startupregister	Startup application form
POST	/startupregister	Submits a new startup application
GET	/startup/:id	Edit form for a pending application (owner-only)
PUT	/startup/:id	Updates a pending application (owner-only)
DELETE	/startup/:id	Deletes an application (owner-only)

Investor (/) — requires login

Method	Route	Description
GET	/investordashboard	Investor overview: request analytics
GET	/browsestartups	Browse all approved startups
GET	/myrequests	Investor's sent connection requests

Connection Requests (/) — requires login

Method	Route	Description
POST	/connect/:startupId	Investor sends a connection request to a startup
POST	/connectionrequest/:requestId/accept	Startup owner accepts a request
POST	/connectionrequest/:id/reject	Startup owner rejects a request

Chat (/) — requires login

Method	Route	Description
GET	/chat/:requestId	Renders the chat room (only for accepted requests, participants only)

Feedback (/) — requires login

Method	Route	Description
GET	/feedback	View feedback form + submission history
POST	/feedback	Submit new feedback

---

Real-Time Chat (Socket.IO)

Authentication for sockets mirrors the HTTP layer — the same JWT cookie is parsed on connection, so no separate socket login step is required.

Client → Server events

• joinRoom(connectionRequestId) — authenticates the socket, verifies the request is accepted, confirms the connecting user is either the investor or the startup owner on that request, then joins the Socket.IO room.
• sendMessage({ connectionRequestId, text }) — persists the message to MongoDB and broadcasts it to everyone in the room.

Server → Client events

• joinedRoom — confirms successful room join.
• receiveMessage — broadcasts a new message (senderId, senderName, senderRole, text, time) to all room participants.
• errorMessage — returned for unauthenticated, unauthorized, or invalid room actions.

---

Validation & Security

• Input validation — every write endpoint (register, startup, feedback, message) is validated through a dedicated Joi schema before it reaches the controller, with stripUnknown: true to prevent mass-assignment of unexpected fields.
• Password policy — enforced via regex: minimum 5 characters, at least one uppercase letter, one lowercase letter, one digit, and one special character.
• Institutional email pattern — registration emails must end in .muet.edu.pk or .com.
• Authorization checks — ownership is verified at the controller level for every mutating action (e.g. a student can only edit/delete their own startup; only a startup's owner can accept/reject a request targeting it).
• httpOnly JWT cookie — mitigates XSS-based token theft; the token is never exposed to client-side JavaScript.
• Centralized error handling — a custom ExpressError class plus an WapAsync wrapper funnel all async controller errors into a single Express error-handling middleware.

---

Project Structure

ORIC Task/
├── controllers/
│   ├── auth.js
│   ├── chat.js
│   ├── connectionRequest.js
│   ├── feedback.js
│   ├── form.js
│   ├── investor.js
│   └── student.js
│   └── startup.js
├── models/
│   ├── ConnectionRequest.js
│   ├── Feedback.js
│   ├── Messages.js
│   ├── Startup.js
│   └── User.js
├── routes/
│   ├── auth.js
│   ├── chat.js
│   ├── connectionRequest.js
│   ├── feedback.js
│   ├── form.js
│   ├── investor.js
│   ├── startup.js
│   └── student.js
├── validations/
│   ├── FeedbackJoi.js
│   ├── MessagesJoi.js
│   ├── StartupJoi.js
│   └── UserJoi.js
├── views/
│   ├── Investor/
│   │   ├── browseStartups.ejs
│   │   ├── investorconnections.ejs
│   │   └── myrequests.ejs
│   ├── startupApplication/
│   │   ├── myApplications.ejs
│   │   ├── startupregister.ejs
│   │   └── startupUpdate.ejs
│   ├── chat.ejs
│   ├── dashboard.ejs
│   ├── feedback.ejs
│   ├── generalizeForm.ejs
│   ├── investorDashboard.ejs
│   └── login.ejs
├── public/
│   └── images/
├── middlewares.js
├── mongoose-connection.js
├── index.js
├── package.json
└── .env

---

Roadmap

• Faculty/ORIC admin dashboard for reviewing and approving/rejecting startup applications (currently no route exists to change status from pending).
• Move the MongoDB connection string into an environment variable for multi-environment deployment.
• Add unread-message counters and notification badges to the chat system.
• Add pagination to browsestartups, myrequests, and investorconnections.
• Move flash-style error messages from raw res.send() strings to rendered EJS partials with proper styling.
• Add automated tests (unit + integration) for controllers and Socket.IO event handlers.

---

Author

Abdul Muheet Computer Engineering, Mehran University of Engineering and Technology (MUET), Jamshoro Built as part of an ORIC MUET internship project.