How to Write a Computer Science Capstone

The capstone is the part of a computer science degree where everything you learned meets a real project. It is also often the best item on your resume, because it shows what you can build from start to finish, not just what you can do in a homework problem.

This guide covers how to choose and scope a project, plan the work, collaborate, test and document, and present the result.

What a capstone is for

A capstone aims to show that you can:

1. Define a problem and its requirements.
2. Design a solution and justify your choices.
3. Build it with sound engineering practices.
4. Test it and evaluate how well it works.
5. Work with others and communicate clearly.

Think of it as a rehearsal for professional work.

Common formats

• Client project: a team builds software for a real organization, such as a nonprofit or a campus office.
• Product project: a team designs its own product and builds a prototype.
• Research project: you test a hypothesis or evaluate an algorithm, often with a faculty advisor.
• Industry-sponsored project: a company proposes a problem and mentors the team.
• Open-source contribution project: you work on an existing project and report on your contributions.

Read your program's guidelines to see which are allowed and how they are graded.

Choosing a topic

Use these criteria.

1. Genuine interest. You will spend months with it.
2. Clear users and need. Know who benefits and how you will tell.
3. Feasible scope. Be honest about time and skills.
4. Learning value. Choose a project that stretches you in a useful direction.
5. Available resources. Check data, hardware, accounts and permissions.
6. Career fit. A project aligned with the jobs you want makes an excellent portfolio piece.

Examples include a scheduling tool for a volunteer group, a mobile app for tracking study habits, a recommendation system for a campus library, a machine learning model for classifying images in a research lab or a security scanner for small websites.

Scoping: the most important skill

Scope problems sink more capstones than technical difficulty. Use a method.

1. Write the goal in one sentence.
2. List features and rank them as must have, should have and nice to have.
3. Define a minimum viable version that delivers value.
4. Estimate effort, then add a buffer of at least thirty percent.
5. Agree on what is out of scope and write it down.

If you finish the must-haves early, add should-haves. If you fall behind, cut nice-to-haves without drama.

Working in a team

Team capstones succeed on communication.

• Agree on roles, while staying flexible.
• Choose a workflow, such as short sprints with a weekly review.
• Use version control, with branches and pull requests.
• Review each other's code.
• Meet regularly with a short agenda.
• Keep a shared task board.
• Handle conflict early by discussing facts and expectations.

Address uneven contributions quickly and respectfully, and involve your advisor if needed.

Working with a client

If you have a client, treat them like a professional partner. Clarify the problem, ask for examples and data, show prototypes early, accept feedback gracefully and be honest about limits. Confirm requirements in writing and agree on how the software will be handed over and maintained.

Planning the semester

A sample timeline for a fifteen-week term looks like this.

Protect time at the end, because last-minute bugs are common.

Design and implementation

Write a short design document before coding heavily. Include a diagram of the main components, data models, interfaces and key decisions with reasons. Choose technologies you can learn quickly, and prefer simple, well-supported tools to trendy ones. Build vertical slices: a thin version of the whole system that works end to end, then add features.

Testing

Testing is part of the deliverable.

1. Unit tests for core logic.
2. Integration tests for components working together.
3. User testing with real people.
4. Edge cases and error handling.
5. Performance and security checks appropriate to the project.

Report your test results in the final report. If something fails, describe the failure and your response honestly.

Documentation

Good documentation sets strong projects apart. Include a README that explains what the project does, how to install and run it, and how to contribute. Add comments for tricky code, API documentation if relevant and a user guide. How to write a technical report explains how to structure the written report, and the guide to commenting and documenting code covers inline documentation habits.

The final report

A typical capstone report includes:

1. Abstract.
2. Introduction and problem statement.
3. Related work or background.
4. Requirements.
5. Design.
6. Implementation.
7. Testing and evaluation.
8. Results and discussion.
9. Limitations and future work.
10. Conclusion and references.

Write as you go, keeping notes in a project log.

The demo and presentation

Plan a live demo that tells a story: here is a user with a problem, here is how our system helps. Prepare a backup, such as a recording, in case of technical issues. Practice with the exact equipment you will use. Keep slides short, explain your design choices and be ready to discuss trade-offs and limitations.

Showcasing the project afterward

Host the code in a clean repository, add screenshots and a short description, and link it from your resume and profile. Write a brief summary of the problem, your role and the results. If the client agrees, include their feedback.

A worked example of scoping

Suppose a team wants to build "a study app." That goal is too fuzzy. After talking to students, they refine it: a web app that lets a student create study sessions, invite classmates and track hours, with reminders. The must-haves are accounts, session creation, invitations and an hours dashboard. The should-haves are reminders and calendar sync. The nice-to-haves are badges and analytics.

They estimate each feature in days, add a buffer and plan three two-week sprints. By the first demo, accounts and session creation work. By the second, invitations and the dashboard are done. The third sprint covers reminders, testing and polish. Because the scope was written down, they can cut badges without regret when a teammate gets sick.

Using a risk list

Keep a short list of risks: a third-party service might change, a key teammate might be unavailable, the data might be messy. For each, write what you will do. Review it at each weekly meeting. Teams that name risks early are rarely surprised by them.

Ethics and privacy

If your capstone collects user data, think about privacy, consent and security from the start. Store only what you need, protect passwords properly and explain how data is used. If you use data from people, check whether your school requires review. Include a section on ethical considerations in your report. Employers and faculty value students who notice these issues.

Handling common crises

Capstones hit predictable problems. A key library does not work as documented: build a small test, search issue trackers and have a fallback. A teammate falls behind: talk early, offer help and redistribute tasks if needed. The client changes requirements: write down the change, estimate its cost and negotiate what moves out. A bug appears the night before the demo: have a stable tagged version you can fall back to. Planning for these makes them less frightening when they occur.

Common mistakes

• Choosing too large a scope.
• Delaying testing and documentation.
• Skipping version control discipline.
• Working in silos and integrating at the end.
• Ignoring the user.
• Underestimating the final report.
• Having no backup for the demo.

Final thoughts

A strong capstone shows judgment as much as technical skill. Choose a real problem, scope it carefully, build in small steps, test as you go and communicate clearly. The result will be a project you are proud to show and a story you can tell in every interview.