Semester Project

This is the project you'll be working on for the rest of the semester. You'll work in teams of four, build one frontend application, keep everything in one shared GitHub repository, and use AI to help you build it.

The first deliverable is not code. It's a pitch presentation, due Saturday, August 8.

AI will get you to "it works" faster than you expect. That's not the finish line. The rest of the semester is scope, polish, and the hundred small things that separate a demo from something a person would actually use.

The Rules

Rule	Detail
Team size	Exactly four members
GitHub	Every member needs their own account
Repository	One per team, all four added as collaborators
Contribution	Every member must have commits under their own account
Stack	Frontend only — vanilla JS, or a JavaScript framework
AI	OpenCode, ChatGPT, Claude, Copilot — use whatever you want
Scope	Big enough to fill a semester, even with AI helping

Team Setup

Do all of this before the pitch. It's fifteen minutes of work and it proves your team is real.

Everyone creates a GitHub account

All four members. Use an email you'll still have access to in December.

Write down each member's username — you'll need it for the pitch slide and I'll use it to check contributions.

One member creates the repository

Pick a member to own the repo. Create it on GitHub with a README.md.

Name it something recognizable — cafe-order-system, not project or finalproject2.

Add the other three as collaborators

In the repository: Settings → Collaborators → Add people, then enter each teammate's username.

Collaborators must accept the invitation by email or from their GitHub notifications. An invitation that was never accepted means that person cannot push, and they will discover this at the worst possible moment.

Everyone clones the repo

Each member, on their own machine:

git clone https://github.com/USERNAME/REPO-NAME.git

Everyone makes one commit

Before the pitch, each of the four members adds their name to the README.md and pushes. Four names, four separate commits, four different accounts.

This is your proof that all four of you can actually push to the repo. Find out now, not in week six.

What Counts as Big Enough

Your project must take the whole semester with AI helping you. That's a higher bar than you think, because AI is fast at exactly the part you're imagining right now.

A project is big enough if it has:

At least five distinct screens or views — not five sections of one page.
At least three features that hold and change state — a cart, a score, a saved list, a filter, a booking.
Data-driven rendering — content comes from JavaScript data, never from copy-pasted HTML.
Responsive design — it works on a phone and on a laptop.
Polish — empty states, input validation, confirmations, loading states, transitions, a consistent visual design.

The one-sitting test. If you could describe your whole app to an AI in one prompt and have something working by the end of the evening, it's too small. Add screens, add features, add depth.Most teams pitch something too small and don't realize it until week four.

Frontend Only

Everything runs in the browser. There is no server, no database, and no API you control.

You can use	You cannot use
HTML, CSS, vanilla JavaScript	A backend of any kind — Express, PHP, Laravel, .NET
A JavaScript framework — React, Vue, Nuxt, Next, Svelte	A real database — MySQL, PostgreSQL, MongoDB, Firebase
npm packages, a build step, a dev server	Server routes, API routes, or anything under `server/`
`localStorage` to save data	User accounts with real passwords
Hardcoded JSON / JS data files	Payment processing
Google Fonts, icon libraries, CSS frameworks	A language that isn't JavaScript or TypeScript

Choosing Your Stack

Vanilla HTML, CSS and JavaScript is the default, and it's a completely valid choice. Every concept this course has taught you applies directly, and nothing stands between you and the code.

A JavaScript framework is allowed if someone on your team already knows it. React, Vue, Nuxt, Next, Svelte, Astro — your pick, as long as it's JavaScript or TypeScript. Declare it at the pitch.

A framework raises the bar on the one rule that decides your grade.AI is extremely good at producing framework code — hooks, composables, stores, routing, patterns nobody on your team has seen before. It will hand you two hundred lines that work perfectly and that none of you can explain. At the defense, that is worth less than fifty lines of vanilla JavaScript you wrote and understood.Pick a framework because a teammate genuinely knows it and can teach the other three. Do not pick one because it sounds more impressive. It isn't, and I will ask.

If you use a framework

Node and npm are tooling, not a backend. A dev server and a build step are fine. server/, /api routes, Express, and database drivers are not.
Nuxt and Next must be static or SPA only. No SSR against live data, no server routes. npm run generate (or next export) has to produce a folder of files that runs on its own.
Add node_modules/ to .gitignore before your first push. A repo with node_modules committed is unusable for your teammates and unreadable for me.
Your app must still run for me from a clean clone: npm install, one command, done. Write both commands in your README.

What this means in practice

"Saving data" means localStorage. Your data lives in one browser on one computer, and that's fine — just be honest about it in your README.
"Logging in" means a fake login screen backed by localStorage. It's a demo of the interface, not real security. Never treat it as real.
"Products" or "levels" or "menu items" live in a JavaScript array of objects that you write.

The frontend-only limit is what makes this project gradeable. Every line in your repo is a line the four of you can read, run in a browser, and explain. Add a backend and half your codebase becomes a place your grade goes to hide.

Project Directions

Anything is fair game as long as it clears the size bar. Some directions:

Type	Example	What makes it semester-sized
Cafe / restaurant	Order system with a menu, cart, order queue, and receipt	Menu browsing, customization, cart math, order history
Store	Online shop with categories, cart, wishlist, checkout flow	Filtering, search, cart state, multi-step checkout
Game	Puzzle, quiz, tower defense, idle clicker, card game	Game loop, scoring, levels, save state, leaderboard
Booking	Salon, clinic, or court reservation	Calendar UI, time slots, conflict handling, confirmations
Tracker	Habit, budget, fitness, or study tracker	Data entry, charts, history views, streaks
Learning	Flashcards, language drills, typing trainer	Deck management, progress tracking, statistics
Event	Ticketing, seat picker, event listings	Seat map, filtering, cart, ticket generation

Bring your own idea if you have one. The best projects usually come from somebody on the team having an actual problem to solve.

The Pitch Presentation

Due: Saturday, August 8 Length: 5–8 minutes per team, all four members speak

What your presentation must cover

The Team

All four names and all four GitHub usernames, on one slide.

The App, In One Sentence

A ______ for ______ that lets them ______.

If you can't finish that sentence, you don't have an idea yet — you have a category.

Who It's For

Who uses this and what problem it solves for them. Be specific. "Students" is not specific. "Students who share a dorm and split grocery costs" is.

The Screens

List every screen or view. Minimum five. For each one, one line on what a user does there.

The Features

Split into must-have (the app is pointless without it) and later (nice to have if time allows). Four to six must-haves is a healthy number.

Your Stack

Say what you're building it with: vanilla HTML/CSS/JS, or a named JavaScript framework.

If you're picking a framework, say who on the team already knows it and how they'll bring the other three up to speed. "We'll learn it from the AI" is not a plan — it's how you end up with a codebase nobody can defend.

Why This Takes a Semester

Address it directly. Which parts are genuinely hard? What has to be polished? What's the part you're least sure how to build?

This slide is the one I'll push back on hardest.

Look and Feel

Two or three reference websites, a rough wireframe, a sketch on paper, a colour palette — anything that shows you've thought about how it looks. A photo of a whiteboard is completely acceptable.

Who Does What

Rough ownership of feature areas across the four of you. Not "designer, programmer, tester" — everybody writes code. Split by feature: who owns the cart, who owns the menu, who owns the game loop.

The Repository

Show it live. The repo, the four collaborators, and four commits from four different accounts.

Pitch Grading

Category	Points
Clarity of the idea — can we all picture the app?	20
Scope — is it semester-sized, and did they justify it?	20
Screens and features are specific, not vague	20
Repository set up correctly with all four contributing	20
All four members present and can answer questions	10
Look and feel — evidence of design thinking	10
Total	100

A team that shows up with a repo containing commits from only one account loses 20 points immediately. Set it up this week.

Contribution Requirements

Your commit history is the record of who did the work. There is no other record, and "he did most of it but I helped" is not one.

Commit under your own account

Configure Git once on your machine, using your own GitHub email:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Never push your teammate's work from your machine. Their commits must come from their account.

Pull before you push

Four people in one repo means conflicts. Every time you sit down to work:

git pull

Then work, then commit, then push. Skipping the pull is how you spend an evening fixing a merge instead of building a feature.

Split by files, not by lines

Two people editing script.js at the same time will conflict constantly. Split your app into separate files by feature area — cart.js, menu.js, game.js — and give each one an owner.

On a framework this is easier: one component per file, one owner per component. Agree on the folder structure at the start so four people aren't inventing four different ones.

Everyone codes

Whatever your team calls the roles, all four members write and commit JavaScript. A member who only made slides has not passed this project.

I will look at the Insights → Contributors page of your repository. It shows commits per person over time. A flat line for one member across the whole semester is visible from across the room.

Using AI on This Project

Use it. That's the course. But the rule from Day 1 hasn't changed:

You may only submit code you can explain.

At every checkpoint, and at the final defense, I'll pick a file from your repo and ask the member who committed it to walk me through it. "The AI wrote that part" is an answer, and it's the wrong one.

Practical habits that keep you out of trouble:

Ask for a plan before code. In OpenCode, that's Plan mode (⇧ ⇥).
Build one feature per prompt, not one app per prompt.
Read the diff before you commit. git diff shows you what actually changed, which is not always what the AI said it changed.
Write your own commit messages. If you can't summarize the change in one line, you don't understand it yet.

See Prompt Flow and OpenCode CLI.

After the Pitch

Once your pitch is approved, the project runs in checkpoints through the end of the semester — roughly: data model and static screens, then core features, then saving with localStorage, then polish and edge cases, then a feature freeze and final demo.

Details come after pitch day, because the checkpoints depend on what you pitch.

Start the repo this week even though no real code is due. Teams that leave the GitHub setup until they need it lose their first working week to invitation emails and merge conflicts instead of building.

Checklist for Saturday

Four members, confirmed
Four GitHub accounts created
One repository created
Three collaborators invited and invitations accepted
Four commits from four different accounts
Presentation covering all ten points above, including your stack
All four members ready to speak