How to choose a capstone project title that panels approve

Most capstone trouble starts at the title. A title that is too wide, too generic, or built on a problem nobody has leads to a weak proposal defense and a painful second semester. This guide walks through the order that works: constraints, domain, user, problem, scope, stack, then the title itself.

Know which requirement you are meeting

CHED Memorandum Order No. 25, Series of 2015 sets the rule for computing degrees in the Philippines. A thesis is required for BSCS. A capstone project is required for BSIT and BSIS. Both are terminal requirements, but a thesis is judged on its research contribution while a capstone is judged on a working system that solves a real problem. Your school’s capstone manual adds its own format and defense rules on top of the CHED order, so get a copy of that manual before you brainstorm.

Step 1: Write down your constraints first

Before you look at any idea list, write the things you cannot change.

• Team size and who is actually going to code.
• Time left, including the weeks for documentation and defense preparation.
• A stack your school requires, if any. Some programs still mandate PHP and MySQL.
• Hardware you own. A machine-learning title on a laptop with 8 GB of memory is a trap.
• Budget for paid services such as SMS gateways, maps, or AI APIs.
• Your adviser’s preferences. Some advisers reject whole domains, so ask before you commit.

Constraints remove most bad ideas in one pass. Students who skip this step spend weeks on titles they could never ship.

Step 2: Pick a domain you actually understand

Choose a setting you have seen from the inside: a sari-sari store, a barangay office, a clinic a relative runs, a school department, a small logistics business. Avoid domains you would have to fake, such as hospital operations, bank compliance, or industrial manufacturing, unless a team member has real experience there. Panels ask domain questions, and the answers show whether you understand the users.

Step 3: Name one real user

A weak title serves “small businesses”. A strong title serves a specific business with a named process you are replacing, such as a paper logbook that tracks eight employees. Ask that user for a short endorsement letter agreeing to be your case study. Panels respect a real beneficiary, and the letter goes in your appendices.

Step 4: Confirm the problem is real

Interview the user before you write a single line of code. Ask what the most frustrating part of the current process is and how much time it takes per day or week. If the answer is “the current process works fine”, stop and find another problem or another user.

Step 5: Right-size the scope

The most common capstone failure is over-scoping. Plan a system you can finish in about 60 percent of the time you have, so testing, evaluation, documentation, and defense preparation get the rest.

A right-sized capstone usually has five to ten database tables, two or three user roles, and one clear core workflow. An over-scoped capstone trains its own AI models, integrates with hardware you have never used, or promises features for every stakeholder in the organization.

Step 6: Use a stack you can already use

Capstone is not the time to learn a new framework from zero. Build on what you already know and spend the saved time on testing and documentation. If your school requires a specific stack, that decision is made for you.

Step 7: Check that the title is unique enough

Search your school’s past titles and the public lists of capstone ideas. A title that has been done many times is not automatically rejected, but you need a clear difference: a new beneficiary, a new feature set, or a measured improvement over the existing system. Copying a free source code project and renaming it is the fastest way to fail a title hearing.

Step 8: Write the title

Philippine panels expect a title that names the system, its type, its main function, and its beneficiary. A common pattern is “a web-based [function] system for [specific beneficiary]” or “[System name]: a mobile [function] application for [beneficiary]”. Keep it under about fifteen words, avoid marketing adjectives, and make sure every word in the title shows up as a feature or a chapter in the documentation.

A short checklist before the title hearing

• Every constraint from Step 1 is respected.
• The beneficiary is named and has agreed in writing.
• The problem was confirmed in an interview, with notes you can cite.
• The scope fits in 60 percent of the available time.
• The stack is one your team has already used.
• You can explain in one minute why this title is different from similar systems.

Where we fit in

Karakoa builds capstone and thesis systems with consultation for students who want a working system and a defense they can pass. We help you pick a scope that fits the calendar, build the system with you, and walk you through every part of the code so you can answer the panel yourself. See the capstone and thesis service page for what is included.