Step 1: Audit what your team can already do
Write down, per member, the languages and tools they have actually built something in — not the ones they have watched a course about. This list is your real capability, and your project should overlap with at least two entries on it.
The exception is when you deliberately want to learn something new. That is legitimate, but treat it as a cost: add three weeks to your plan and pick a smaller scope elsewhere to pay for it.
Step 2: Check the constraint that kills the project
Every domain has one dependency that decides whether the project is possible at all. Find it before you commit, not after.
| Domain | The constraint to check first |
|---|---|
| AI / ML | Does a usable, licence-compatible dataset exist? Download it in week one. |
| IoT / Embedded | Are all components available, and what is the delivery time to your address? |
| Blockchain | Can you explain why a database is insufficient for this use case? |
| Cloud | Is there a managed service interaction, or is this just hosting? |
| Mobile | Do you have a test device that is not the developer's own phone? |
| Full stack | Is the module list small enough to finish, with a workflow rather than only CRUD? |
Step 3: Write the review-day sentence
For each shortlisted idea, write one sentence describing exactly what you will show the panel: what you click, what appears, and why it is impressive. If you cannot write that sentence, the idea is not concrete enough yet.
This exercise eliminates a surprising number of ideas. Projects that sound good in a proposal often have nothing visible to demonstrate, and a review is a visual event.
Step 4: Size the scope against your calendar
Count the weeks you actually have, then subtract everything that will steal time: placement drives, internal examinations, festival holidays, and the two weeks documentation genuinely takes. What remains is your build window, and it is usually about half of what you assumed.
- Two members with a heavy placement season: choose a Beginner scope, finish it perfectly.
- Three or four members with a clear semester: an Intermediate project with one advanced component.
- A strong team with prior experience in the domain: an Advanced project, with a fallback plan for the ambitious part.
Step 5: Validate with your guide before building
Take a one-page scope to your guide: problem, users, modules, technology and timeline. Ask two specific questions — is the scope acceptable, and is the domain permitted. A guide who signs off on this page will rarely object later.
Ask about mandatory elements too. Some departments require hardware, a minimum number of surveyed papers, or a specific report format. Discovering these in month three is expensive.
Warning signs you picked the wrong project
- Two weeks in and nobody has written code that runs, only read documentation.
- The dataset you planned to use turns out to need permission you cannot get.
- Every discussion is about which framework to use rather than what to build.
- The demo depends on something outside your control, like a paid API quota or a shared campus network.
- Nobody can explain the project to a friend from another branch in two sentences.
It is cheaper to switch in week two than to struggle until week ten
Teams stay with a failing idea because switching feels like wasted effort. It is not. A week spent proving an idea is unworkable is a week well spent, and the second choice is usually better because you now know what to check.
If you are stuck between options, look at our project catalogue and pick something close to one of the listed projects. Starting from a known-feasible scope and customising it beats inventing from scratch under deadline pressure.