Most students choose a final year project by scrolling a list of titles and picking whichever sounds most impressive. Then they spend February discovering what it actually involves. There is a better method, and it takes about an hour.
Step 1 — Count the weeks you actually have
Take your submission date. Subtract four weeks as a buffer, because you will need them for guide-requested changes and things that break. Then subtract your exam weeks, any placement drives, and festival breaks when nothing gets done.
Most students who think they have twenty-four weeks have about eleven usable ones. Do this arithmetic before you look at a single topic — it eliminates half the list on its own and saves you the disappointment later.
Step 2 — Decide what you want on the other side
Three legitimate goals, and they point at different projects:
- Marks. Pick something conventional, execute it unusually well, and document it perfectly. A hospital management system with real conflict detection and a matching ER diagram scores higher than a shaky AI project.
- A job. Pick something in the stack you want to be hired for, and build it as a portfolio piece. Interviewers ask about final year projects for the first two years of your career.
- Higher study. Pick something with a research angle, and plan for a paper alongside it. That changes the topic materially — you need novelty, not just working software.
Trying to serve all three produces a project that does none of them well. Pick one, and let it decide.
Step 3 — Find out what your batch is doing
This is the step everyone skips, and it does more damage than any other. When fifteen students submit variations of the same library management system, the panel becomes hostile by the fourth one — through no fault of the fourth student.
Ask around before you commit. If your topic is already taken, either change it or change its domain substantially: the same technical system applied to an entirely different problem is a different project, and defensible as one.
Step 4 — Ask what question the project will attract
Every project has one question a panel will inevitably ask. For a chatbot it is how you stop it inventing answers. For a booking system it is what happens with simultaneous bookings. For a machine learning project it is what your model gets wrong.
Work out what that question is before you choose, and ask whether the prospect of answering it interests you or frightens you. If it frightens you, that feeling does not improve over six months — it arrives at the viva unchanged.
Step 5 — Take three options to your guide, not one
Arriving with one topic invites a yes or no. Arriving with three, each with a two-line description and an honest difficulty assessment, invites a conversation — and guides give far better input when they are choosing rather than judging.
Ask them, explicitly:
- Has anyone in a recent batch done something close to this?
- Is the scope right for the time available, in your experience?
- What will the panel focus on for a project like this?
- What is the format and deadline for the synopsis?
Step 6 — Write the scope down before you build
One page. What it will do, what it will explicitly not do, which technologies, and a week-by-week plan with the dates from step one. Get your guide to agree to it.
That page is what protects you when scope drifts in January, and its “will not do” section becomes your answer when a panel asks why the system lacks some feature. Declared limits are a design decision. Undeclared ones are an oversight.
The mistakes that recur every single year
- Choosing on title rather than substance. “AI-powered blockchain healthcare platform” is four projects, and you will finish none of them.
- Deciding late. Every week spent undecided is a week removed from the build, and it never comes back.
- Building before approval. A topic rejected in week six is the most expensive mistake available to you.
- Leaving the report to the end. Write each chapter as you finish the corresponding work. Reports written in the final week always look like reports written in the final week.
- Assuming you will understand it later. If you cannot explain a module the week you build it, you certainly will not in March.
If you already know what you want, it can be built to your problem statement — and if you do not, the topic lists are a reasonable place to start: MCA, BCA, and B.Tech.