Course Project Guidelines

The course project is a substantial collaborative undertaking in which teams of 2 to 4 students design and build a full-stack web application.

Your project should meaningfully apply modern web development concepts and technologies covered in the course, including areas such as TypeScript, frontend development, server-side logic, relational data, cloud file storage, and application integration. You are expected not only to implement these components, but also to make appropriate technical choices, explain important design decisions, integrate the components into a coherent system, and provide evidence that the application behaves as intended.

Project Deliverables · Project Idea · Project Proposal · Team Health Check · Presentation · Final Project Deliverable · Tips

Project Deliverables

The course project consists of three major deliverables:

1. Project Proposal (due Sunday, November 8, 2026, 11:59 PM): 15% of final grade

   • A Markdown document outlining the project’s motivation, objectives, features, and tentative plan.

2. Presentation (delivered during Lectures 11 and 12, Friday, November 27 & December 4, 2026): 10% of final grade

   • An 8-minute in-class presentation consisting of a 6-minute project presentation followed by 2 minutes of Q&A. The presentation should showcase your project’s features and technical implementation based on the work completed by November 26, 2026. Although project development may continue until the Final Project Deliverable deadline, only work completed by November 26 may be included in the presentation to ensure fairness across presentation sessions.
   • The presentation will be graded 5% by peer review and 5% by instructor & TAs using the same rubric.

3. Final Project Deliverable (due Sunday, December 6, 2026, 11:59 PM): 35% of final grade

   • Source Code: Delivered as a public or private Git repository on GitHub. Ensure that your repository is well-organized, with clear structure and comments.
   • Final Report: A detailed report to ensure full reproducibility of your work, delivered as a README.md file in your GitHub repository.
   • AI Interaction Record: If AI meaningfully influenced your project, document 2–4 meaningful interactions in an ai-session.md file in the GitHub repository. If your team used little or no AI, briefly state that instead.
   • Video Demo: A video demonstration of your project, lasting between 2 and 5 minutes. The demo should highlight the key features and functionality of your application. Include the video URL in the ## Video Demo section of your final report (the README.md file).

Project Idea

The course project represents a more innovative and time-consuming piece of work than the individual assignments. It is designed to simulate a realistic, collaborative full-stack development experience and consists of four key stages: team formation, project proposal, in-class presentation, and final deliverable submission by the specified deadline.

Your course project MUST be a full-stack web application implemented using TypeScript and MUST incorporate the following technologies and features:

Core Technical Requirements

Advanced Features (Must implement at least two)

• User Authentication and Authorization: Support authenticated users with appropriate access control. This typically includes:

  • User registration and login
  • Session or token-based authentication
  • Protected routes or APIs
  • Role-based or permission-based access control (if applicable)

  Recommended framework: Better Auth 

• Real-Time Functionality: Support live, real-time updates without requiring a page refresh. Examples include:

  • Live notifications
  • Real-time collaboration or chat
  • Live status updates or dashboards

• File Handling and Processing: Perform non-trivial server-side or client-side processing on uploaded files. Examples include:

  • Editing, transforming, or validating uploaded files
  • Parsing structured file formats (e.g., CSV, JSON, images, PDFs)
  • Generating derived files or previews
  • Applying business logic based on file contents

  Note: Simple file upload and download does not count as an advanced feature, as it is part of the Core Technical Requirements.

• Advanced State Management: Manage complex or shared state that cannot be handled cleanly with local component state alone. Examples include:

  • Global client-side state shared across many components
  • Derived or computed state with clear update logic
  • State synchronization across views or sessions

  Recommended tool: Redux Toolkit 

• Integration with External APIs or Services: Integrate meaningfully with external systems beyond your own backend. Examples include:

  • Third-party data APIs
  • External authentication or identity providers
  • Payment, messaging, or analytics services
  • Cloud-based AI or data-processing APIs

Note on Project Requirements and Scope

Your project MUST implement all core technologies and at least two advanced features. To ensure a focused and achievable project within the ~2 month timeline, avoid the following scope pitfalls:

• Too simple (e.g., a basic CRUD app without meaningful features), which will not demonstrate sufficient mastery of course technologies
• Too complex (e.g., distributed systems or machine-learning-heavy features), which are difficult to implement effectively within the course timeline
• Too broad (e.g., a full-scale social media platform), which often leads to shallow or incomplete implementations

The goal is to develop a well-scoped, thoughtfully implemented application that effectively showcases your understanding of modern web development using the required technologies. A successful project should have a clear purpose, achievable scope, and polished implementation of core features.

Remember: A well-executed, focused project is far more valuable than an overly ambitious one that cannot be completed properly within the course timeline. While creativity and innovation are encouraged, please keep in mind that this is a course project with specific learning objectives to achieve.

Example Project Ideas

Below are some illustrative project ideas to guide your team. Smaller teams (2 members) may implement a subset of features, while larger teams (3–4 members) should aim for more features or added complexity.

These examples are not fixed blueprints. The listed technologies and features are suggestions to illustrate scope and complexity, not strict requirements.

Whether based on these examples or entirely original ideas, all projects must fulfill the Core Technical Requirements and include at least two advanced features.

Teams are encouraged to propose unique project ideas tailored to their interests and expertise, provided the scope is realistic and achievable within the project timeline.

1. Collaborative Document Annotation Platform

   A web application that allows users to upload documents (e.g., PDFs) and collaboratively annotate them in real-time.

   Key features:

   • User authentication and team management
   • Role-based permissions (Admin, Editor, Viewer)
   • Real-time collaborative annotations and comments
   • Annotation categorization and filtering
   • Document version history
   • Search functionality across documents and annotations
   • Email notifications for mentions and replies
   • Document preview with pagination
   • Export annotations in various formats
   • PostgreSQL for structured data
   • Cloud storage for document handling

2. Personalized Learning Platform

   A system where educators can create and share interactive educational content (e.g. videos and PDFs).

   Key features:

   • User authentication with different roles (Teacher, Student)
   • Course creation and management
   • Interactive content builder (quizzes, assignments)
   • Progress tracking and analytics dashboard
   • Discussion forums for each course
   • Assignment submission and grading
   • Calendar integration for deadlines
   • Certificate generation upon completion
   • PostgreSQL for structured data
   • Cloud storage for educational content

3. Event Ticketing and QR Code Check-in System

   A full-stack platform for event management and ticket processing.

   Key features:

   • User authentication (Organizer, Staff, Attendee)
   • Event creation with customizable registration forms
   • Tiered ticket pricing and discount codes
   • QR code generation and validation
   • Real-time check-in dashboard
   • Attendance analytics and reporting
   • Automated email confirmations
   • Waitlist management
   • Mobile-responsive check-in interface
   • PostgreSQL for transaction data
   • Cloud storage for event assets

4. Online Code Collaboration Tool

   A real-time coding environment where users can write and execute code collaboratively.

   Key features:

   • User authentication and workspace management
   • Real-time code editing
   • Basic syntax highlighting for 2-3 popular languages
   • Project organization (folders and files)
   • Team/group management
   • Chat functionality
   • Code snippet saving and sharing
   • Custom theme settings (light/dark mode)
   • PostgreSQL for user and project data
   • Cloud storage for code files

5. Scientific Conference Management System

   A simplified OpenReview clone for managing academic paper submissions and reviews, with different roles having distinct permissions and workflows.

   Key features:

   • Role-based access control (Author, Reviewer, Chair)
   • Paper submission system with metadata and PDF uploads
   • Double-blind review process
   • Review assignment and management
   • Discussion threads for each submission
   • Automated email notifications
   • Decision management and response periods
   • Conference timeline management
   • PostgreSQL for structured data
   • Cloud storage for paper submissions

6. Collaborative Data Analysis Platform

   A web-based platform where data scientists can upload datasets, create visualizations, and collaborate on analysis projects in real-time.

   Key features:

   • User authentication and team workspace management
   • Dataset upload and management (CSV, JSON, Excel)
   • Data visualization using existing libraries (e.g. Chart.js )
   • Data table view with sorting and filtering
   • Dataset metadata management
   • Sharing permissions (public/private, team access)
   • Comments and annotations on visualizations
   • Export visualizations as images
   • PostgreSQL for metadata and user data
   • Cloud storage for dataset files

Project Proposal

The project proposal should be submitted as a single file in the form of a Markdown document  (with the .md suffix in the filename), with a maximum length of 2000 words. Other formats (such as Microsoft Word or Adobe PDF) will not be accepted, as Markdown is the industry standard for technical documentation in software development.

Required Sections

Your proposal should include the following four sections. Keep the discussion clear, concise, and technically grounded. The goal is not to maximize length or complexity, but to demonstrate that your team has thought carefully about what you plan to build, why the design is appropriate, and how you arrived at your decisions.

Marking Rubric

The proposal is evaluated based on the quality of the team’s reasoning, planning, communication, and technical judgment.

The stated requirements define what must be addressed; the rubric evaluates how effectively and thoughtfully those requirements are addressed.

The following anchor scores are used throughout the rubric:

• 95 — Exceptional: Meaningfully exceeds normal course expectations through unusually strong reasoning, clarity, or technical judgment.
• 80 — Strong: Clearly and correctly meets course expectations with sound reasoning and planning.
• 70 — Satisfactory: Meets the basic expectations, but has noticeable weaknesses, limited depth, or insufficient justification.
• 55 — Needs Improvement: Has significant gaps, weaknesses, or misunderstandings.
• 0 — Missing / Inadequate: Missing or fundamentally fails to address the criterion.

Anchor scores are used by default. Intermediate scores may be awarded when the work clearly falls between two adjacent performance levels.

Depth is valued over breadth: additional content, features, technologies, or complexity do not by themselves earn a higher score.

Submission

Submit a single Markdown document to the assignment labeled Project Proposal in Quercus  by November 8 2026, 11:59 PM.

Each member of the team must make their own submission on Quercus. All members of the same team should submit the identical document.

![Image Name](https://example.com/image.png)

Confidential Team Health Check

Each student must complete a brief confidential Team Health Check individually via Quercus Quiz (the link will be posted later through a Quercus Announcement) by Wednesday, November 18, 2026, 11:59 PM.

The check-in is intended to identify collaboration or contribution issues early enough for them to be addressed before the final project deadline. It consists of five multiple-choice questions and one optional short-answer question about team functioning, participation, communication, workload distribution, and project progress.

If your team is working well and you have no concerns to report, the quiz should take only a few minutes to complete.

Responses are confidential and will not be shared directly with other team members. They may be considered, together with Git history, project artifacts, stated team responsibilities, and other available evidence, when assessing Individual Contribution in the Final Project Deliverable.

A concern raised in the Team Health Check does not automatically result in a grade adjustment. Individual grades will be adjusted only when the overall project evidence indicates a meaningful contribution imbalance.

Presentation

Each team will deliver an 8-minute presentation session during Lecture 11 (November 27, 2026) or Lecture 12 (December 4, 2026) to showcase the project’s features and technical implementation as completed by November 26, 2026.

Each team will have:

• 6 minutes for the presentation
• 2 minutes for Q&A with the instructor and TAs

Presentation slots will be randomly assigned and announced by November 2, 2026.

Teams may designate one or two members to deliver the 6-minute presentation. However, all team members must attend both sessions to provide peer feedback and should be prepared to participate in Q&A about their project. Exceptions will be granted only to part-time MEng students with unavoidable work conflicts.

Submission

• Submit a written project introduction (70–100 words) individually via Quercus  by Wednesday, November 25, 2026, 11:59 PM.
  • This introduction is used to set up peer review forms and to publish a preview of projects on the course website.
  • During the presentation, teams are still expected to introduce the project themselves as part of the 6-minute presentation.
• Submit presentation slides individually via Quercus  by Thursday, November 26, 2026, 11:59 PM.
  • All team members must upload the same file to ensure fairness.
  • During the presentation, teams are expected to use the same slides submitted to Quercus. Minor revisions such as typo fixes are acceptable, but no substantive content changes are allowed after November 26, 2026.
  • The instructor and TAs will compare the presented slides with the submitted version. Substantive content added or changed after the deadline will result in a deduction from the instructor & TAs presentation score.

Content Requirements

• Core Requirements (Mandatory): Demonstrate all core technical requirements. At a minimum, your presentation should clearly show:

  • A working frontend implemented with React or Next.js (TypeScript)
  • A functioning backend/server layer implemented with TypeScript (Next.js full-stack or Express.js)
  • Persistent relational data storage using SQLite or PostgreSQL
  • Basic file handling using cloud storage
  • Clear frontend–backend integration, including meaningful data flow and state updates

  A live demo is required and must showcase at least one meaningful part of the working application. Short recorded clips may be used as a backup for network-dependent components or for behavior that is difficult to reproduce reliably during the presentation, but they may not replace the live demo entirely (see Presentation Logistics).

• Advanced Features: Present at least two advanced features.

  • If an advanced feature is already implemented, briefly demonstrate it and explain its purpose, design, and integration with the rest of the application.
  • If an advanced feature is not yet implemented, clearly explain its design, support the explanation with a simple mockup, diagram, example, screenshot, or partial implementation, and provide a concrete and feasible plan for completing it by December 6, 2026.

• Clearly highlight the application’s overall architecture, key user flows, and integration among frontend, backend/server logic, database, storage, and advanced features.

Expectations

• Scope and Fairness: The presentation must showcase only the work completed by November 26, 2026.

  Development may continue after this date, but any new features or major changes completed after November 26 must not be included in the presentation.

• Core Requirements: By November 26, all core requirements must be functional and demo-ready in a local development environment or deployed environment.

  Deployment is not required for this course project. If your application is deployed, you may present and demo the deployed version, but deployment itself does not replace any core technical requirement.

• Advanced Features: May still be in progress at the time of presentation, but teams must provide a clear, realistic explanation and a concrete completion plan.

• Demo: Each team must include a live demonstration of at least one meaningful part of the working application during the presentation. The live demo should provide direct evidence that the project is functional and should ideally showcase one or more core technical requirements.

  Short recorded clips may be used as a backup for network-dependent components or to demonstrate behavior that is difficult to reproduce reliably within the presentation time (see Presentation Logistics). However, a presentation consisting entirely of pre-recorded demonstrations is not permitted.

  Brief code snippets, architecture diagrams, database schemas, or API examples may also be shown where they help explain the implementation.

• Communication: Presentations should be clear, concise, and technically focused. Slides and brief notes may be used as prompts, but presenters should not rely on reading from a prepared script. Clear explanation and natural delivery are part of the evaluation. Detailed expectations and support resources are available in the Project Presentation Guidelines.

Q&A

Each presentation will be followed by approximately 2 minutes of Q&A with the instructor and TAs.

The Q&A will typically include one main question, with a brief follow-up where appropriate. Questions may address topics such as:

• application architecture or technology choices;
• frontend–backend integration and data flow;
• database or state management;
• cloud storage and file handling;
• advanced feature design;
• technical tradeoffs or limitations; or
• remaining work before the final project deadline.

All team members should understand the major technical aspects of their project and be prepared to participate in Q&A, even if they are not one of the designated presenters.

The goal is not to test memorization, but to give teams an opportunity to demonstrate their understanding and practice communicating technical ideas in a dynamic setting.

Grading

• The presentation is worth 10% of the final grade:

  • 5% peer evaluation
  • 5% instructor & TA evaluation

• Both use the same Presentation Rubric, which evaluates:

  • Clarity & Communication
  • Technical Progress & Demonstration
  • Advanced Features & Completion Plan

• Peer reviewers evaluate only what is clearly demonstrated or explained during the presentation and Q&A; they are not expected to verify underlying implementation details.

• Peer scores are normalized across both presentation days for fairness.

Final Project Deliverable

The final project deliverable should be submitted as a URL to a public or private GitHub repository. If your repository is private, add the instructor and TAs (GitHub usernames: cying17, ZihangH, and XindanZhang) as collaborators so that it can be read.

Your repository must contain:

1. A final report (README.md)
2. Complete source code
3. An AI interaction record (ai-session.md)
4. A video demo
5. Deployment URL (if deployed)

Final Report

A README.md file serves as the final report, in the form of a Markdown document  with a maximum length of 5000 words ^{1 2}. If you include images (e.g., screenshots), ensure they are visible when the instructor or TAs view your GitHub repository in a web browser.

The report should clearly and concisely cover the following aspects:

• Team Information: List the names, student numbers, and preferred email addresses of all team members. Make sure these email addresses are active as they may be used for clarification requests.

• Motivation: Explain why your team chose this project, the problem it addresses, and its significance.

• Objectives: State the project objectives and what your team aimed to achieve through the implementation.

• Technical Stack and Architecture: Describe the technologies used, including the chosen architecture approach (Next.js full-stack or separate React + Express), database solution, cloud storage, and other key technologies.

• Features: Outline the main features of your application and explain how they fulfill the course project requirements and achieve your objectives.

• User Guide: Provide clear instructions for using each main feature, supported with screenshots where appropriate.

• Development Guide: Include steps to set up the development environment, covering:

  • Environment setup and configuration
  • Database initialization
  • Cloud storage configuration
  • Local development and testing

• Deployment Information (if applicable): Provide the live URL of your application and relevant deployment platform details.

• AI Assistance & Verification (Summary): If AI tools contributed to your project, provide a concise, high-level summary demonstrating that your team:

  • Understands where and why AI was used
  • Can evaluate AI output critically
  • Verified correctness through technical means

  Specifically, briefly address:

  • Where AI meaningfully contributed (e.g., architecture exploration, database queries, frontend/backend integration, debugging, documentation)
  • One representative mistake or limitation in AI output (details should be documented in ai-session.md)
  • How correctness was verified (e.g., manual testing of user flows, logs, unit or integration tests)

  Do not repeat full AI prompts or responses here. Instead, reference your ai-session.md file for concrete examples.

• Individual Contributions: Describe the specific contributions of each team member, aligning with Git commit history.

• Lessons Learned and Concluding Remarks: Share insights gained during development and any final reflections on the project experience.

Source Code

Your repository must contain all source code required to build and run the project. This includes the complete implementation of both frontend and backend/server components, along with necessary configuration files. The source code should be well-organized in a logical directory structure, following standard practices for your chosen tech stack (Next.js or React + Express).

Required components include:

• All application source files
• Environment configuration templates
• Database schema definitions and migrations
• Cloud storage integration/configuration files where applicable
• Essential documentation (such as API endpoints for separate frontend/backend projects)
• Testing files (if implemented)

Make sure your repository includes clear instructions in the Development Guide section of your README.md for setting up and running the project locally. Any environment variables or sensitive credentials should be properly documented but not committed to the repository. If your project requires specific configuration for cloud services or external APIs, provide clear setup instructions or template files.

Your code should follow consistent formatting and include appropriate comments for complex logic. Consider including a .gitignore file to exclude unnecessary files and dependencies from version control.

AI Interaction Record

Your repository must include a file named ai-session.md to provide concrete evidence supporting the AI Assistance & Verification section in README.md.

If AI meaningfully influenced your project, document 2–4 representative AI interactions that meaningfully influenced the project. These interactions should illustrate:

• Responsible and transparent use of AI tools
• Your team’s ability to critically evaluate AI output
• How AI-generated suggestions were validated, adapted, or corrected in the context of your application

For each interaction, include:

## Session Title (e.g., Diagnosing unexpected UI behavior)
 
### Prompt
 
<copy/paste>
 
### AI Response
 
<copy/paste, trim, or summarize if long>
 
### What Your Team Did With It
 
1-3 bullet points describing:
 
- What was useful
- What was incorrect, misleading, incomplete, or not applicable
- How your team verified, modified, or replaced the suggestion

If your team used little or no AI, briefly describe that instead. You are not expected to create AI interactions solely for the purpose of this record.

There is no word limit for this file.

You do not need to include every AI interaction. If you have several to choose from, select examples that best demonstrate judgment, evaluation, and verification rather than trivial edits or formatting help.

Video Demo

Include a 2–5 minute video demo, showcasing:

• Key features in action
• User flow through the application
• Technical highlights
• Deployment (if applicable)

The video’s URL must be included in the ## Video Demo section of the final report (the README.md file). Host the video on a platform like YouTube, Dropbox, or Google Drive, ensuring access for the instructor and TAs. If under 100 MB, the video may be included directly in the GitHub repository.

Marking Rubric

The final project is evaluated based on the quality of the system your team has built, your technical understanding and judgment, and the evidence that the system works as intended.

The stated project requirements define what must be implemented; the rubric evaluates how effectively, correctly, and thoughtfully those requirements are implemented.

The following anchor scores are used throughout the rubric:

• 95 — Exceptional: Meaningfully exceeds normal course expectations through unusually strong reasoning, clarity, technical execution, integration, or engineering judgment.
• 80 — Strong: Clearly and correctly meets course expectations with sound implementation and engineering decisions.
• 70 — Satisfactory: Meets the basic expectations, but has noticeable weaknesses in implementation, integration, technical depth, or insufficient justification.
• 55 — Needs Improvement: Has significant gaps, technical issues, or incomplete understanding.
• 0 — Missing / Inadequate: Missing or fundamentally fails to address the criterion.

Anchor scores are used by default. Intermediate scores may be awarded when the work clearly falls between two adjacent performance levels.

Depth and quality are valued over breadth: additional features, technologies, code, or complexity do not by themselves earn a higher score.

The first four criteria below assess the team project. Individual Contribution is assessed separately for each student.

Submission

Submit a single URL — the URL to your team’s GitHub repository — to the assignment labeled Final Project Deliverable in Quercus . Each team member must submit individually; however, all members of the same team should submit the same repository URL.

Tips and Suggestions

Using GitHub for Project Management and Collaboration

GitHub can be useful not only for storing code, but also for coordinating work across a team. You are encouraged to explore the GitHub features that help your team organize tasks, review changes, and keep track of important project context.

• Commit Frequently with Meaningful Messages: Keep commits reasonably focused and use a consistent format (e.g., fix: ..., feat(api): ...). A clear commit history makes changes easier to understand and can also provide useful context when reviewing individual contributions.
• Use Branches and Pull Requests: Branches and pull requests can help separate substantial pieces of work, support code review, and make integration easier when multiple team members are contributing.
• Use GitHub Issues for Task Management: GitHub Issues can serve as a shared task tracker for features, bugs, and follow-up work. You can assign issues to team members and use labels or milestones to organize them.
• Explore GitHub Discussions for Team Communication: GitHub Discussions provides a space for longer-form questions, brainstorming, and design conversations that you may want to keep associated with the project. You do not need to move every team conversation there; use it when having a persistent discussion record would be useful.
• Explore GitHub Wiki for Project Documentation: A Wiki can be useful for longer-lived notes such as design ideas, setup instructions, technical decisions, or lessons learned. It is one option for organizing project knowledge; your README or other project documentation may serve similar purposes.

Check this page for a step-by-step guide on using GitHub to manage tasks and collaborate effectively.