WDD 430: Web Full-Stack Development


Project Support Links

Team Project Description

Overview

You will work in your team to design, develop, and deploy a full-stack web application using Next.js. This project will demonstrate your ability to apply contemporary workflows, use a modern framework, collaborate effectively using agile methods, conduct peer code reviews, build relevant technical documentation, and build a production-ready application.

This is a block-long project, with incremental deliverables each week. You will apply concepts learned in class while exploring additional features independently. By the end of the course, you will have a deployed, functional web application that showcases your full-stack development skills.

Specifications

The final application must include the following technical requirements and features:

Technical Requirements

Minimum Features and Functionality

Team Workflow

Professional Application: Managing the Project Effectively

This project is designed to simulate professional team development in an accelerated timeline. The practices below help teams stay organized, reduce risk, and deliver meaningful progress throughout the block.

1. Use MVP Definition

Define the smallest set of features that delivers clear user value, and place all non-essential ideas in a "Phase 2" backlog. Teams that protect MVP scope are more likely to ship a stable, complete solution.

2. Define Clear Tasks and Ownership

Each GitHub issue should represent 4–8 hours of work (a small feature or component). Assign one primary owner per issue. This prevents confusion and ensures accountability. Use issue labels (backend, frontend, bug, docs) to organize work.

3. Establish Weekly Iteration Planning both Synchronously and Asynchronously

Your team should:

This keeps your board a living tool, not a static artifact.

4. Make Database and Deployment Decisions Early

Choose your database (PostgreSQL, MongoDB, or similar) and hosting approach (Vercel or similar platforms) early in the project. Early platform decisions reduce late-stage blockers and integration surprises.

5. Develop Component-Driven Architecture

Build reusable components early and share them across your team. A ProductCard component written once can be used on multiple pages. This multiplies your productivity.

6. Use Frequent Code Reviews as Sanity Checks (not as a gatekeeping device)

At least one other team member should review each Pull Request before merging. The goal: catch bugs and maintain consistency, not perfection. A good code review takes 15–20 minutes, not an hour. The course has these formallyl scheduled, however, each team should set a 24-hour turnaround expectation.