Pick an FYP that matches the role you want, solves a real problem for a real user, uses the tools that role uses, and that your group can finish and deploy. A modest idea done properly, with clean code, tests and a clear demo, helps far more in interviews than an ambitious idea that never fully works.
What people tell me
My final year project proposal is due soon and I am stuck choosing an idea. Everyone wants to do something with AI because it sounds impressive, supervisors want something research-heavy, and my group members all want different technologies. I want a project I can actually talk about in interviews and that helps me get a job after graduating, not just something that passes the evaluation.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Choose the FYP for the job you want: web, mobile, data, AI or systems. Interviewers will ask about it in depth.
- Real users and a real problem make a stronger story than a buzzword.
- Scope it so you finish and deploy. A working modest system beats an unfinished ambitious one.
- Divide work so every member owns a real part they can explain.
- Treat it like a product: Git, issues, tests, a README and a demo video.
Why the FYP matters more than people think
For many students, especially in Pakistan where the final year project (FYP) is a year-long group effort, it is the largest piece of software they have built before their first job. Interviewers know this. They will ask you to walk through it, explain your part, justify your choices and talk about what went wrong. A project you understand deeply is worth more than a project with an impressive title.
Four questions to choose an idea
- Which role do I want after graduation? Pick an idea that uses that role's tools.
- Who is the user? A real person or organisation you can talk to is ideal.
- Can we finish and deploy it in the time we have? Be honest about your group.
- Can I explain my part in five minutes to a stranger? If not, rethink it.
Match the project to the role
| Target role | Good FYP direction | What to show |
|---|---|---|
| Web or full stack | A multi-user platform for a real organisation (clinic, school, NGO, shop) | Auth, roles, database design, API, deployment |
| Mobile | An app with offline support, notifications and a backend | State handling, sync, releases to a test track |
| Data or analytics | A dashboard and pipeline on real public or partner data | Cleaning, modelling, clear insights, reproducibility |
| AI engineering | An AI feature inside a useful product, with evaluation | Retrieval or model choice, testing quality, cost and failure handling |
| Machine learning | A focused model on a real dataset with honest evaluation | Baselines, metrics, error analysis, not just accuracy |
| DevOps or cloud | A system with CI/CD, monitoring and infrastructure as code | Pipelines, containers, logs, alerting |
The final year project ideas library groups ideas by area and difficulty if you want starting points.
A note on AI projects
AI is a fine choice when the AI part serves a real use and you can measure whether it works. It is a weak choice when the whole project is a thin wrapper around a chat API with a new interface. If you go the AI route, show how you evaluated results, what happens when the model is wrong and how you kept costs down.
Scope it properly
Write the idea as three layers:
- Must have: the smallest version that is useful. Build this first.
- Should have: features that make it good.
- Could have: extras only if time allows.
Most FYPs fail because the group starts with the "could have" list. Get the core working and deployed by the midpoint, then improve.
Split work so everyone can explain something
| Member | Owns | Can talk about in interviews |
|---|---|---|
| A | Backend and database | Schema design, API, performance choices |
| B | Frontend or mobile | UI state, usability, integration |
| C | Data, AI or integrations | Model or pipeline, evaluation, edge cases |
| D | Testing, deployment, docs | CI, hosting, test strategy, README |
Rotate code reviews so everyone reads everyone else's code. It helps in viva and in interviews.
Run it like a real team
- One Git repository with branches and pull requests from day one.
- An issue board with small, clear tasks.
- Weekly check-ins with short notes.
- A few automated tests for the most important logic.
- A README with setup steps, architecture diagram and screenshots.
- A 3-minute demo video recorded before the final evaluation.
These habits are exactly what the University to job-ready roadmap calls job-ready.
A first 4 weeks after approval
| Week | Goal |
|---|---|
| 1 | Talk to the user, write the must-have list, choose the stack, set up the repository |
| 2 | Database design and skeleton app running end to end |
| 3 | First must-have feature working and deployed to a test environment |
| 4 | Second feature, first tests, first demo to supervisor and user |
How to present the FYP on your resume
Treat the FYP as your strongest experience entry, not a line under education. Write it like this:
- Title and one line: what the system does and for whom.
- Your role: "Owned the backend and database design for a four-person team."
- Two or three outcomes: "Designed a schema for 12 entities, built 30 API endpoints, deployed on a cloud VM with automated tests on every pull request."
- Link: repository, demo video or live site.
In interviews, prepare a two-minute version and a ten-minute version of the story, including one decision you would change today and why. That reflection is often what interviewers remember.
Common mistakes
- Picking the idea for the title, not the learning.
- Choosing a stack nobody in the group knows and learning it too late.
- One member doing everything while others "handle documentation".
- Leaving deployment to the last week.
- Not keeping any record of decisions, so nobody can explain them later.
If you are still stuck
If your degree felt theory-heavy, read I am graduating soon and feel like I learned four years of theory but cannot build software and From CSE graduate to your first software engineering job. If you want another pair of eyes on your idea before the proposal is due, join Sefism (free to learn, with credits on joining) and ask your own question with your shortlist.
Was this answer helpful?
Read next
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open: sign up and your account is active shortly after. Prefer to talk? A free call works too.