Is Major Cooked? Free AI risk score + roast for your college major
Solo Era solo activities, solo maxxing, sidequests, challenge
Keepsake Project Management, Freelancers, DesignersCapstone project ideas for CS and IT students: 12 scoped builds
A good capstone project solves a real problem for a named user, fits in one semester for a team of two or three, and ends in evidence: a working system, tests, an evaluation with real users or data, and a report. Choose a core flow you can finish in ten weeks, then add two supporting features. Below are 12 ideas, six leaning towards computer science and six towards IT, each with scope, deliverables and a time estimate, followed by a sample rubric you can compare with your program's own.
How big should a capstone project be?
A capstone is the final project of a degree, meant to pull your courses together on one problem. Programs differ on team size, length and what counts, so read your handbook first. This page assumes a common shape: a team of two or three, one semester of about 15 weeks, and a supervisor who meets you every week or two. If your rules differ, keep the proportions and change the numbers.
| Question | Right size | Too big | Too small |
|---|---|---|---|
| Core user flow | One flow works end to end by week 6 | Three flows, none finished | A form that saves to a table |
| Components | 3 to 5 you can name and draw | A dozen services | One script |
| Users | A named group you can reach for a test | "Everyone" | Only the team |
| Hard part | One technical problem that needs real design | Five open research questions | Nothing you could not do in a course lab |
| Evidence | A test with real users or real data in week 12 | A survey after the demo | Screenshots |
Scope is the thing most capstones get wrong, and it nearly always goes in one direction. Cut features until the core flow is boring, then spend the saved weeks on testing and evaluation, which score more than extra screens. The MVP scope planner and the guide to scoping an MVP can help you decide what to drop.
What deliverables does a capstone project need?
Expect the following, in roughly this order. Ask your supervisor which are mandatory and in what format.
- Proposal (1 to 2 pages, week 2): problem, user, scope, risks, plan.
- Requirements (week 4): user stories or numbered requirements, each testable, plus what is out of scope.
- Design document (week 6): architecture diagram, data model, the main technical decision and the options you rejected.
- Working system (week 11): deployed or runnable from a README, with seed data.
- Test report (week 12): what you tested, how, results, known defects.
- Evaluation (week 12): a test with real users or real data, with numbers and quotes.
- Final report and demo (weeks 14 and 15): problem, approach, results, limits, what you would do next.
- Repository: history showing each member's work, a README, and instructions another student can follow.
Title: Team and roles: Supervisor: 1. Problem (3 sentences): who has it, how they cope today, what it costs them. 2. User and client: name the person or group who agreed to test it. 3. Core flow: one sentence, from first click to useful result. 4. Scope: three things we will build. Three things we will not. 5. Hard part: the technical problem we will solve, and how we will know we did. 6. Evidence: how we will evaluate (users, data, measures) and the success threshold. 7. Risks and fallbacks: top 3, with a plan for each. 8. Milestones: weeks 2, 4, 6, 8, 11, 12, 14, 15. 9. Ethics, privacy and security: data we will hold, and who can see it.
| Weeks | Focus | Done when |
|---|---|---|
| 1 to 2 | Pick a client and a problem; write the proposal | Supervisor and client have signed off |
| 3 to 4 | Interviews, requirements, risk list | Every requirement has a test idea |
| 5 to 6 | Walking skeleton: one thin flow through every layer, deployed | A teammate can run it from the README |
| 7 to 10 | Build the core flow; add one supporting feature per team member | Core flow passes its tests |
| 11 | Feature freeze; fix, document, seed data | No new features after this week |
| 12 to 13 | Evaluate with users or data; fix the top defects | Numbers and quotes collected |
| 14 to 15 | Final report, slides, rehearsed demo | Demo works offline as a fallback |
How is a capstone project graded? A sample rubric
Universities publish their own criteria and those always win. The rubric below is an illustration of how weight is commonly spread, written so you can check your project against the likely questions. Notice that implementation is one criterion of seven; the rest reward thinking, proof and communication.
| Criterion | Points | Meets expectations | Exceeds |
|---|---|---|---|
| Problem and requirements | 15 | A named user, a clear problem, testable requirements | Evidence from interviews or data that the problem is real |
| Design and architecture | 15 | Diagram, data model, one justified decision | Rejected options compared with reasons and measurements |
| Implementation quality | 20 | Works as specified, readable, version-controlled | Clean structure, sensible error handling, easy for others to extend |
| Testing and verification | 15 | Automated tests for the core flow, a manual test log | Tests at several levels, failure cases, continuous integration |
| Evaluation | 15 | Tried with real users or data, with results reported | Baseline comparison, honest limits, follow-up changes shown |
| Security, ethics and accessibility | 10 | Data handling explained, basic checks done | Threat model, privacy review, accessibility check |
| Communication | 10 | Clear report and a working demo | Reader-friendly report, a calm demo with a prepared fallback |
Looking for a client? Ask a department office, a club, a local charity or a small business what repeated chore costs them time. The board of ideas is another source of real problems, with a ready build prompt for each. If you want to start with a published idea, browse by topic such as education, health or developer tools.
Which capstone project ideas suit computer science students?
These lean on algorithms, systems or data. Each has a technical core that needs design, not just assembly. Time estimates are total build hours for a team of two to three, excluding the report.
01 Autograder for programming assignments
A service that runs student code against hidden tests in an isolated container, with limits on time and memory.
- Stack
- Python or Go, Docker containers with resource limits, Postgres, a queue.
- Concepts
- Process isolation, resource limits, concurrency, threat modelling, similarity detection.
- Time estimate
- 250 to 350 team hours.
First version: upload a file, run it against a fixed test set in a container with CPU, memory and wall-clock limits, and show pass or fail per test. Deliverable highlight: a threat model listing what malicious student code might try, and a test for each item.
Stretch: a similarity report using token n-gram fingerprints. Evaluate it on a seeded set where you know which submissions were copied, and report false positives. Present it as a prompt for human review, never as proof of cheating.
02 Course planner with prerequisite checking
Students enter taken courses and get a plan that respects prerequisites, offering terms and credit limits.
- Stack
- TypeScript or Python, Postgres, a graph library or your own.
- Concepts
- Directed graphs, cycle detection, topological ordering, constraint satisfaction.
- Time estimate
- 200 to 300 team hours.
First version: import your department's course list with permission, validate that the prerequisite graph has no cycles, and check a student's plan for violations with a clear message for each.
Stretch: generate a four-year plan under offering constraints, then evaluate it against plans that ten real students or an adviser made by hand: how many were valid, and how many did the tool improve?
03 Lab equipment booking with QR check-in
Book a microscope, 3D printer or oscilloscope by time slot, with no double bookings and a maintenance log.
- Stack
- Django, Rails or .NET, Postgres, QR codes, email notifications.
- Concepts
- Concurrency, exclusion constraints on time ranges, roles, notifications.
- Time estimate
- 200 to 280 team hours.
First version: staff add equipment, students book slots, and the database refuses overlapping bookings for the same item. A test that fires two simultaneous requests for one slot is a required deliverable.
Stretch: QR check-in, automatic release of no-shows after 15 minutes, a maintenance calendar that blocks slots, and a usage report the lab manager can use to justify new equipment.
04 Remaining useful life prediction for jet engines
Predict how many cycles an engine has left from its sensor readings, and make the model's uncertainty usable.
- Data
- NASA's Turbofan Engine Degradation Simulation (C-MAPSS) data in the NASA Prognostics Data Repository.
- Stack
- Python, scikit-learn or PyTorch, pandas.
- Concepts
- Run-to-failure data, splitting by engine, asymmetric error costs, baselines, uncertainty.
- Time estimate
- 150 to 250 team hours.
First version: a baseline that predicts remaining life from the latest cycle's readings, a better model on windows of recent cycles, and error reported per engine. Split by engine, never by row, or the score is inflated.
Stretch: penalise predicting failure too late more than too early, add prediction intervals, and write a model card on what the model should not be used for. See also machine learning project ideas.
05 Accessibility audit pipeline for a university website
Crawl a site, run automated checks on every page, and publish a dashboard that shows which pages need work first.
- Stack
- Playwright, axe-core, a database, GitHub Actions.
- Concepts
- WCAG success criteria, crawling, prioritisation, CI reports, manual audit methods.
- Time estimate
- 180 to 260 team hours.
First version: crawl 100 pages with the web team's agreement, run axe on each, store violations and show a page-by-page list sorted by impact.
Stretch: manually audit 10 pages, compare your findings with the automated ones and report what automation missed. Add a CI gate so that a new violation fails a build. The comparison is the strongest evidence in the report.
06 Shift coordination for a volunteer organisation
Volunteers see open shifts, sign up, get reminders, and a coordinator sees gaps before the day.
- Stack
- Any web stack, Postgres, email or messaging reminders, calendar export.
- Concepts
- Requirements elicitation, roles and permissions, scheduling rules, privacy of personal data.
- Time estimate
- 180 to 260 team hours.
First version: the coordinator posts shifts with a required headcount, volunteers claim them, and the page shows red for unfilled shifts. Interview three real coordinators before you design anything.
Stretch: reminders, waitlists, a calendar feed using the iCalendar format, and a trial across one real event with a before and after count of time spent by the coordinator.
Which capstone project ideas suit IT students?
IT capstones lean on operations, networks, cloud and security. They are judged on reliability, documentation and how well they fit how an organisation works. Build and test in labs you own; never run attack or scanning tools against systems you are not authorised to test.
01 Network inventory and configuration drift detector
Collect device configs nightly, store versions, and flag any change that breaks a written policy.
- Stack
- Python, Netmiko over SSH, virtual devices in Containerlab or GNS3, Git or Postgres for versions.
- Concepts
- Network automation, idempotence, configuration diffing, change control.
- Time estimate
- 180 to 260 team hours.
First version: collect running configs from five virtual devices each night, store each version, and show a diff of what changed and when.
Stretch: policy rules such as no Telnet and a required time server, with a pass or fail report per device, and remediation scripts that only produce a dry-run plan for a human to approve. Evaluate by injecting ten known violations and measuring how many you catch.
02 Helpdesk with priority matrix and SLA clocks
A ticket system where impact and urgency set priority, and response targets pause outside business hours.
- Stack
- Web stack of your choice, Postgres, email intake, a scheduler.
- Concepts
- Incident versus request, priority matrix, SLA timers, escalation, reporting.
- Time estimate
- 200 to 300 team hours.
First version: create tickets from a form or email, compute priority from a matrix, and compute due times that skip nights, weekends and listed holidays.
Stretch: escalation notices, a monthly report, and a replay of last term's anonymised tickets through your SLA logic to show how many would have breached. Agree the data use with the helpdesk first.
03 Log pipeline with detection rules tested by simulated attacks
Collect authentication logs from lab machines, write detection rules, and measure how many simulated attacks they catch.
- Stack
- OpenSearch or a similar log store, Sigma-style rules, Python, three lab VMs.
- Concepts
- Log collection, normalisation, detection engineering, false positives, MITRE ATT&CK mapping.
- Time estimate
- 220 to 320 team hours.
First version: ship logs from three VMs you own, implement five rules (repeated failed logins, a new admin account, a login at an unusual hour), and trigger each one on purpose.
Stretch: run a scripted attack set in the lab, report detection rate and false alarms per rule, tune thresholds, and map each rule to an ATT&CK technique in a table.
04 Cloud cost and idle-resource reporter
Define a small cloud environment as code, then report untagged, idle and oversized resources with read-only access.
- Stack
- Terraform, a cloud provider account with a spending alert, Python, a scheduler.
- Concepts
- Infrastructure as code, tagging, least-privilege access, cost allocation, reporting.
- Time estimate
- 180 to 260 team hours.
First version: Terraform a small stack with required tags, then run a script with read-only credentials that lists resources lacking tags or showing no activity for 14 days.
Stretch: a weekly report by owner tag, a proposal of what to shut down (never done automatically), and a test that a deliberately untagged resource appears in the next report.
05 Indoor air quality sensor network with a live dashboard
Three or more sensors send CO2, temperature and humidity to a dashboard that alerts on stale air.
- Concepts
- Publish and subscribe messaging, buffering when offline, sensor calibration, alert rules.
- Time estimate
- 200 to 300 team hours, plus hardware.
First version: each sensor publishes a reading every minute over MQTT to a broker, a subscriber stores it, and Grafana shows rooms side by side with a threshold alert.
Stretch: store readings on the device when the network drops and send them later, compare one sensor against a reference instrument and publish the error, and document how a facilities team would run it.
06 Moving a department's spreadsheet process into a web app
Replace a shared workbook that a team depends on with a tool that validates data and keeps history.
- Stack
- Web stack of your choice, Postgres, import scripts, role-based access.
- Concepts
- Requirements from non-technical users, data migration and validation, change management, training material.
- Time estimate
- 180 to 280 team hours.
First version: shadow three users, draw the real process (including the workarounds), and import the workbook with a validation report that lists every row it could not accept and why.
Stretch: run old and new side by side for two weeks, count errors in each, write a one-page user guide, and measure time to complete the monthly task before and after.
How do you choose and pitch a capstone project?
- Start from a person, not a technology. A named client who will test your work protects you from an idea that cannot be evaluated.
- Check the hard part. If a teammate could finish it in a lab session, it is too small; if nobody can describe the first step, it is too large.
- Ask for the data or access in week 1. Waiting on a client is the most common reason for slipping.
- Write what is out of scope in the proposal and re-read it whenever a new feature looks tempting.
- Plan the evaluation before the build, so you design something you can measure.
For a wider set of starting points see coding project ideas, computer science project ideas and software engineering project ideas. When the project is done, portfolio project ideas explains how to present it, and if you have a good idea you cannot fit in a semester, post it on the board for someone else to build.
Frequently asked questions
What is a capstone project?
A capstone project is the final, larger project in a degree program in which students apply what they learned to one problem, usually for a real or realistic client. It typically includes a proposal, a working system, testing, an evaluation and a written report with a presentation.
How do I choose a capstone project idea?
Start with a person who has a problem and will test your solution, then check that the technical core is hard enough to need design but small enough to finish in about ten weeks. Ask your supervisor early whether the scope, data and tools are acceptable.
What makes a capstone project good for a resume?
A named user, a deployed or runnable system, a measured result and a clear account of your own contribution. A line such as "cut a coordinator's weekly scheduling time from two hours to forty minutes in a four-week trial" carries more weight than a technology list.
How long should a capstone project take?
Most programs allot one or two semesters, which is about 15 to 30 weeks. A team of three can usually build 200 to 350 hours of work in one semester, alongside other courses. Plan 25 to 30 percent of the time for testing, evaluation and writing.
Can I do a capstone project alone?
Sometimes, if your program allows it, but halve the scope. A solo project should have one core flow and one supporting feature. Teams add coordination work, so a project that suits three people is rarely suitable for one.
Is it acceptable to use AI coding tools in a capstone project?
Check your program's policy first, and disclose use where it requires. If it is allowed, treat the tool like any dependency: you must understand, test and be able to explain every part of the system. Your design decisions, tests and evaluation should remain your own work.
Created with AI assistance and edited for this site. Examples are illustrative and do not represent customer research. About the publisher.