How to Turn Your Capstone Project Into a Portfolio Piece

Turning your capstone project into a portfolio piece means taking it out of the defense folder and making it easy for a stranger to understand in two minutes: put the code in a clean repository you control (with your groupmates' agreement), remove any real personal data, deploy a working demo with sample data, and write a short case study that says what problem it solved and exactly which part you built. Add a two-minute demo video and two or three strong resume bullets, then practice explaining it out loud. Done well, your capstone is usually the strongest proof a fresh grad has.

Most capstones die the day after defense. The code sits on one groupmate's laptop, the documentation is a 120-page PDF nobody outside your panel will read, and the demo only runs on XAMPP on that one machine. Sayang. Here's how to rescue it.

Why is your capstone your best portfolio piece?

Your capstone is usually the biggest, most complete thing you've built: a real problem, a real client or partner, months of work, testing with users and a defense in front of a panel. That's closer to actual job experience than any tutorial project.

Employers know most capstones are group work, and they don't hold that against you. What they want to see is that you understand the system, can describe your part honestly, and can talk through the decisions. Turning it into a portfolio piece is mostly about packaging what you already did.

Step 1: Get the project into a repository you control

Before anything public, sort out ownership and privacy. This is the step people skip, and it's the one that can actually get you in trouble.

1. Talk to your groupmates. Agree that each of you can show the project publicly. Usually the easiest setup is one shared repo under an organization or one member's account, which everyone forks or links to.
2. Check with your adviser and partner organization if the system was built for a real clinic, school, LGU office or business. Some partners won't want their name, data or internal processes public.
3. Remove real personal data. Names, contact numbers, student records, patient info, addresses. Replace them with fake sample data. Under the Philippine Data Privacy Act, real people's data shouldn't be sitting in a public repo. If you're unsure, ask the partner or your adviser, and check privacy.gov.ph for the official guidance.
4. Remove secrets. Database passwords, API keys, email credentials. Move them to a .env file listed in .gitignore. If any real password was ever committed, change it, because old commits keep the history.
5. Credit your team in the README with their names and roles (with their permission).

If your partner says no to a public repo, you can still keep the code private and show a demo video and screenshots with fake data. That's a perfectly good portfolio piece.

Step 2: Clean it up and make it run anywhere

A recruiter can't install your XAMPP setup. Give them something they can click.

• Seed sample data so the demo doesn't open to empty tables. Realistic, fake records: "Maria Santos, follow-up check-up, Oct 24, 10:00 AM".
• Create a demo account for each user role (admin, staff, customer) and list the logins in the README.
• Deploy it. PHP and Laravel apps can run on free or low-cost hosts; static frontends work on GitHub Pages, Netlify or Vercel; Node and Python apps on platforms like Render. Free tiers change their limits, so check current terms. If deployment isn't realistic, a solid demo video covers it.
• Fix the obvious bugs your panel caught. You don't need to fix everything.
• Delete dead code, commented-out blocks and leftover test pages like test2.php.
• Polish one screen. The first screen a visitor sees should look clean on desktop and on a phone.

Don't rebuild the whole thing in a new framework just to look modern. A working PHP and MySQL system you understand beats a half-migrated React version you don't.

Step 3: Write a short case study

The case study is the README or portfolio page that tells the story. Keep it to one screen of reading, in this structure:

1. The problem. "Our partner clinic in Bacolod tracked appointments in a logbook, so patients got double-booked and records went missing."
2. What you built, in one sentence. "A web-based appointment and patient records system for clinic staff."
3. Your part. "I built the scheduling module and designed the database (11 tables)."
4. Tech choices and why. "Laravel because our team knew PHP, MySQL because the clinic's host supported it."
5. One real challenge. "Two staff saving at the same time still created double bookings. I fixed it with a check inside a database transaction."
6. Result and what you learned. "The clinic used it during a two-week test. I learned to test with real users early."
7. Screenshots, the live link, the demo logins and the repo.

Only include numbers you can back up. If the clinic tested it for two weeks with three staff, say that. Don't round it up into "used by hundreds".

Step 4: Record a two-minute demo video

A short screen recording is the fastest way for a busy hiring manager to see your system working. Use the free tools you already have: OBS Studio, the Xbox Game Bar on Windows, or QuickTime on a Mac.

• Keep it under two and a half minutes.
• Show one real task from start to finish (book an appointment, approve it, see it on the dashboard).
• Narrate in simple English: what you're doing and why the screen works that way.
• Upload it as unlisted on YouTube or to a Google Drive link set to "Anyone with the link can view", and test the link in a private browser window.

Step 5: Put it on your resume, GitHub and LinkedIn

Your capstone goes in a Projects section near the top of your resume, right after your summary and skills. Write it like work, not like a title.

• Weak: "Capstone: Clinic Appointment System."
• Strong: "Built the scheduling module and database (11 tables) of a clinic appointment system in Laravel and MySQL; tested with clinic staff during a two-week trial and fixed a double-booking bug using database transactions."

Then pin the repo on GitHub with a clear name like clinic-appointment-system (our guide to a GitHub profile for fresh graduates covers the rest), add the demo video or live link to LinkedIn's Featured section, and link the repo from your resume header. The fresh graduate IT resume guide has more before and after lines you can copy.

You can absolutely do all five steps on your own. The part fresh grads find hardest is the writing: cutting a 120-page system into three honest bullets that a recruiter can scan in ten seconds. In the Fresh Grad Track, that's the week 1 assignment, and a coach sends written notes on your resume before you apply anywhere.

How do you explain your capstone in a job interview?

Use the same six parts as your case study and practice until it fits in about two minutes: problem, solution, your part, tech choices, one challenge, result and lesson. "Tell me about your capstone" is one of the most common fresh grad interview questions, and one of the easiest to win if you've rehearsed it.

Expect these follow-ups:

• Why did you design the database that way?
• How did you handle passwords and user roles?
• What would you change if you built it again?
• How did your team split the work and handle disagreements?

Be honest about group work. "My groupmate built the payment part, but here's how it works" is a strong answer. Interviewers can tell when someone explains code they didn't write. Record yourself on your phone, watch it back, and cut the filler words ("parang", "basically", "ano"). The technical interview tips for fresh graduates cover the rest of that interview, and in the Fresh Grad Track week 3 you record this exact pitch and run it in a technical mock interview with a coach's feedback.

What if your capstone isn't impressive?

Most capstones aren't polished, and that's fine. A few ways to handle a weak one:

• Polish one module instead of the whole system. Show the part you built best.
• Rebuild a small slice of it as a personal project, using cleaner code, and link both.
• Lead with the problem and your learning, not the visuals.
• Add a second project that covers what the capstone doesn't, like a small app with an API.

If you're still in school, it's not too late to make your current capstone portfolio-ready from the start: use Git from day one, write commit messages properly, and keep sample data separate from real data. Want a feel for how the course handles this before deciding? The free Fresh Grad preview lessons need no account, and the IT Job Starter Kit has a resume template.

Frequently asked questions

Can I put my capstone project in my portfolio if it was a group project?

Yes. Get your groupmates' agreement, credit them in the README, and state exactly which part you built. Interviewers expect capstones to be group work and mainly want to see that you understand the system.

What if my capstone partner organization doesn't allow it to be public?

Keep the repository private and show a demo video and screenshots that use fake sample data instead. Remove the partner's name if they prefer, and describe the system in general terms.

Should I rebuild my capstone in a newer framework?

Usually no. A working system you fully understand is better than a half-finished rewrite. If you want to show a newer stack, rebuild one small part as a separate project and link both.

How do I host my capstone for free?

Static frontends can go on GitHub Pages, Netlify or Vercel, and some platforms like Render offer free tiers for small backends. Free tier limits change, so check current terms, and add a demo video in case the free server is asleep when a recruiter visits.

How long should a capstone case study be?

About one screen of reading: the problem, what you built, your part, your tech choices, one real challenge, and the result. Add screenshots, demo logins and the repo link so a reviewer can verify it quickly.