For Students

You’re enrolled in CS 461, 462, and 463, the on-campus, three-term computer science capstone: one team, one project partner or mentor, and one project for the whole year.

Other capstone options (online CS 46X, the one-term CS 467, ECE 441/442/443, ENGR 415/416) are separate sections. The on-campus lectures share a time slot, so switching between CS, ECE, and ENGR is easy.

Browse Projects (CS and ECE)

How You Get Your Project and Team

Project partners (companies, nonprofits, faculty, staff, entrepreneurs) and students submit projects through the same portal. The instruction team reviews each one and lists the approved projects before fall week 0. You rank them in a bidding survey before the term starts, and teams are announced in fall week 1.

Bidding: the default. You rank the projects and we do our best to place you on a top choice, but we can’t guarantee one.
Team size: 3 to 4 students in the usual case. Teams run from 2 to 5 depending on enrollment and what the project needs, and the instructors balance skills and preferences across all of them.
Friends: rank the same projects in the same order. That helps, but it guarantees nothing. The only reliable way to be on a team with your friends is to propose a project together before the term starts.
Your own project: you can propose one of any kind, but it needs a project partner or an approved mentor attached, and that mentor (or an instructor, where there’s no outside mentor) acts as your project partner for the year, evaluations included. If it’s accepted, you and any teammates named in the proposal are assigned to it automatically, and it may never appear in the public list. Submissions close when fall term starts, and every proposal declares whether the project requires an IP agreement, an NDA, or both. If your project doesn’t have a full team yet, complete the regular bidding survey anyway; if not enough students pick it, we’ll place you on another project.
Reserving a spot: not possible, with two exceptions: you submitted the project, or your project partner submitted it in collaboration with you.
Asking a partner beforehand: some project descriptions invite you to contact the partner with questions. Asking doesn’t reserve a spot; the instructors place students.
External partner: every team has one. Some projects arrive with a partner attached. For the rest, the team finds one or more mentors (faculty, industry professionals, or anyone who can move the project forward), approved by the instruction team, and a mentor’s evaluation carries the same weight as a project partner’s. Align expectations with them in your first meeting.
Several teams on one project: some partners take more than one team. Negotiate with the partner what your team owns (an interface, a repository, or a milestone) and how the teams talk to each other, and write your team’s part into its Definition of Shipped.
Outside the class: your team may collaborate with a separate ECE capstone team on a shared project, with a research group, or with people from other colleges, professional organizations, and online communities. Joining an ECE or multidisciplinary (ENGR) team outright means enrolling in that section instead of this one.

What You Do Each Term

Fall: bid on a project, meet your partner, write the team charter, and build a walking skeleton. You defend your own contributions live, and you write an RFC.
Winter: build and verify against real users; define what “shipped” means for your project and run an incident postmortem. Another RFC, another defense.
Spring: release, measure, publish a landing page, hand the project off, and present at the Engineering Expo. A career retrospective closes the year.

Every term, your grade has four equal components, and none of them can be crammed into week 10. The assignments overview has the components, weights, and due weeks.

Lectures

Each week’s slot is a workshop, a guest speaker (industry, faculty, alumni who shipped something), a demo day, or no lecture at all. The schedule says which, what’s due, and what to read first. Check announcements for the meeting times and room.

If the Project or the Team Has to Change

Both are possible, and both need your instructors’ approval, because both disrupt more than your own team.

Changing teams happens only when staying would be worse. Reasons that have justified a change are a conflict mediation couldn’t resolve, a skills mismatch large enough that you’d clearly contribute more elsewhere, and a multi-team project that needs its people rebalanced.

If a concern is building, talk to your Teaching Assistant (TA) or your instructors as soon as possible. We recommend working through the conflict guide first, because a problem raised early can often be fixed inside the team, and a transfer disrupts two teams. To change teams:

Write to the instructors with the reasons and what you already tried inside the team.
An instructor talks to everyone involved and decides.
If the change is approved, both teams agree on a transition plan covering responsibilities, knowledge, and in-flight work, and the reasons, the decision, and the plan are written down.
You’re then assessed on your contributions to each team for the time you were on it, and the grade may be adjusted for the change’s impact on both projects.

Pivoting or changing the project may also mean finding a new project partner or mentor. Teams pivot for reasons like ill-defined requirements, no product-market fit, a problem that turns out to be infeasible, data that can’t be obtained, a disagreement over IP terms, or an irreparable conflict with the partner. Your grade is based on the project you present at each milestone, against the same standards throughout, so a pivot in fall leaves most of the year to meet them, and a pivot in spring leaves one term at most. If you suspect a dead end, say so in your next sprint note and TA check-in. To pivot:

Write down the current path, why it isn’t viable, and how the new direction fixes that.
Revise the scope, timeline, and roles for the time that’s left.
Get your instructors’ approval, and bring your project partner or mentor along, because they evaluate your work.
Restart from whichever point the new direction requires, and expect the extra effort.

Abandoning a project is a last resort. A team that invested substantial effort before factors outside its control ended the project may receive partial credit, based on an exhaustive post-mortem submitted to the instructors.

The Pages You Need

ScheduleWeek by week: what runs in class, what's due, what to read.

Assignments OverviewEvery graded deliverable, its weight, and its due week.

IP, NDA, and LicensingWho owns what you build, and what changes when a project can't be shown in public.

GuidesHow to do the engineering work the assignments assess.

Questions Students Ask

Could this become a company? Yes. You hold the IP by default, you may keep the code closed, and the Project Handoff lets the successor be you. The grade rewards a deployed product with users you don’t know, so launch it publicly rather than building in stealth; the Shipping guide has that path.
Can I reuse my honors thesis? Probably not. Ask the instructors if you think there’s a match.

Resources

Project funds and cloud access go through the instruction team; check announcements for the request form.

Hardware, software licenses, user research, and light marketing: a small budget plus a hardware inventory, all subject to approval.
AWS: shared accounts with a budget cap, wiped at the end of the year, on request.
Azure: some OSU departments host projects built for them; the department, not the instruction team, decides.
HPC and iLabs: open to every engineering student after the mandatory training.

Browse the Hardware Inventory