FYP Ideas for BSCS 2026: How to Choose a Final Year Project That Gets You Hired

FYP ideas for BSCS 2026: why the list is the last thing you need

Every year around this time my inbox fills with the same message: "Sir, please share some FYP ideas for BSCS." Some come from final year computer science students who have a proposal defence in three weeks, some from software engineering students whose group has already changed its idea twice. I understand the panic. But a list of final year project ideas for computer science is the easy part. Anyone can find fifty titles on Google in a minute. What decides whether your FYP helps you get hired is how you choose one, how you scope it, and what you can say about it in an interview a year from now.

So this post does it the other way round. First, how to choose a final year project that recruiters actually care about. Then the mistakes I see most often. Then around fifteen concrete FYP ideas for software engineering and CS students, including AI FYP ideas, grouped by domain, each with a full write-up on Sefism that you can take to your supervisor.

What your FYP is really for

Your FYP does three jobs at once, and most groups only think about the first:

1. Passing the degree. Proposal, SRS, design document, mid evaluation, final defence. Most universities split this into FYP-I and FYP-II across two semesters.
2. Being the biggest thing on your CV. For a fresh graduate with no internship, the FYP is often the only project a recruiter will ask about in detail.
3. Being your first real software team experience. Three or four people, one codebase, deadlines, a client (your supervisor) who changes their mind. That is exactly what your first job looks like.

If you choose only for job one, you pick whatever the supervisor approves fastest. If you choose for all three, you pick differently.

How to choose a final year project that gets you hired

1. Start from a real problem, not a technology

"We want to do something in blockchain" is not a project. "Small shopkeepers in our area keep credit (udhaar) in a paper register and lose track of who owes what" is a project. The second one tells you who the users are, what success looks like and what the hard parts will be.

A simple test: can you describe the problem in one sentence without naming a single technology? If not, keep looking.

2. Find real users you can actually reach

The best FYPs I have reviewed had five to ten real people using them before the final defence: a tuition centre owner, a pharmacy, a society at your university, a clinic near your house. Real users give you three things no textbook project has: bug reports you did not expect, a story for your interview, and proof that the thing works.

If you cannot name at least one person outside your group who would use it, that is a warning sign.

3. Scope it to fit two semesters, then cut again

Most groups overestimate what they can build by at least half. A rough shape that works:

The key idea is the first slice: one feature working end to end (UI, API, database, deployed somewhere) before the FYP-I evaluation. Groups that build the login screen, then the dashboard, then the database, usually have nothing working until month nine.

4. Pick a supervisor who will actually review your work

A famous name on the approval form is less useful than a supervisor who meets you every two weeks and asks hard questions. Before you commit, ask seniors how that supervisor runs meetings, how quickly they reply, and whether their groups finish on time. If your department allows it, a co-supervisor from industry is worth a lot.

5. Split the team by ownership, not by "frontend guy and backend guy"

The most common FYP team failure is one person doing 80% of the work. The second most common is a split where nobody understands the whole system, which then shows in every interview.

A better split is by feature ownership: each member owns one or two features end to end (their screens, their API, their tables, their tests). Everyone can then explain the architecture, and everyone has something specific to talk about. Use Git properly from day one: branches, pull requests, and at least one teammate reviewing each change. If a teammate stops contributing, deal with it early. I wrote about that in how to handle a teammate who does not contribute.

6. Know what recruiters actually ask about FYPs

When I interview fresh graduates, I rarely care what the project was called. I ask things like:

• What problem does it solve, and who used it?
• Draw the architecture. Why this database? Why this framework?
• What was the hardest bug, and how did you find it?
• What did you build, specifically?
• If ten thousand people used it tomorrow, what would break first?
• What would you do differently?

If your project lets you answer all six with real detail, it has done its job. If the honest answer to "who used it?" is "our supervisor, once", it has not. I answered this in more depth in which final year project will actually help me get a job.

Common FYP mistakes I see every year

Another chatbot wrapper. A UI on top of an LLM API with a system prompt is a weekend project, not a two semester one. Examiners have seen dozens, and recruiters can tell. AI FYP ideas are great, but the work has to be in the parts around the model: retrieval over real documents, evaluation, guardrails, cost, latency, handling Urdu or Roman Urdu input, and measuring whether the output is right. If you are not sure where AI fits, read am I falling behind if I am not building AI projects.

Unscoped IoT. "Smart home with 20 sensors, a mobile app, a web dashboard and machine learning" usually ends as three sensors on a breadboard that work only in the lab. Good IoT projects pick one physical problem (a water tank that runs dry, a poultry shed that overheats) and solve it reliably, including power cuts and flaky Wi-Fi.

Copying a senior's project. Supervisors notice, and you learn nothing you can talk about.

Choosing by stack buzzwords. Microservices, Kubernetes and blockchain in a project with fifty users is a red flag in an interview, not a strength. Use boring technology unless the problem needs something else.

No deployment. A project that only runs on one teammate's laptop cannot be shown to anyone. Deploy early, even to a free tier.

Leaving the report to the end. Write the report as you go: decisions, trade-offs, what you measured. It is also your interview script.

A curated set of FYP ideas with real problems behind them

Sefism has a library of final year project ideas, each scoped to finish, with a suggested stack, team size, milestones and what to show examiners. These are the ones I would point a Pakistani BSCS or BSSE group to first, because each has real users close to home and real engineering underneath.

Small business and fintech

• Voice-first udhaar ledger app for small shopkeepers: an Android credit ledger where entries are spoken, not typed, with offline storage and customer reminders. Real users are in every street.
• Payment confirmation app against fake screenshots: helps small merchants confirm a mobile wallet or bank transfer actually arrived before handing over goods.
• Bank and mobile wallet statement reconciliation: matching statements to sales records is a daily chore for small businesses, and a good data modelling problem.
• Tuition centre fee and attendance manager: a beginner-friendly web app with a clear client. Good for a smaller group.

E-commerce and logistics

• Courier dispatch with cash on delivery reconciliation: much of online retail in Pakistan still runs on COD, and reconciling cash, returns and payouts is a genuinely hard backend problem. Advanced, suits a group of four.
• COD return analytics for small online sellers: a data project on why orders get refused at the door and what sellers can change.

AI and machine learning

• Roman Urdu and English customer message triage: sorting a small business inbox by intent and urgency when customers write in mixed Roman Urdu. A far better AI FYP than a generic chatbot, because the language is the hard part.
• Urdu and English phone booking voice agent for clinics and salons: advanced, but a real product shape with real latency and accuracy trade-offs.
• Retrieval assistant for university regulations: RAG done properly, with citations and evaluation, over documents your own university publishes.
• Crop disease detection from phone photographs: computer vision with a clear user and a hard data collection problem.

Mobile and civic

• Load-shedding schedule and outage alerts: schedules, reminders and crowdsourced outage reports, built to work when power and internet are both down.
• Blood donor matching and request coordination: a problem that WhatsApp groups solve badly today.
• Municipal complaint tracking with response deadlines: a beginner web project with workflow, roles and reporting.

Security

• On-device SMS scam detector for mobile wallet users in Roman Urdu: privacy-preserving classification on the phone, for a scam pattern almost every family has seen.

IoT and embedded (scoped properly)

• Rooftop water tank level and pump controller with dry-run protection: one sensor, one relay, one real problem. A good example of an IoT FYP that finishes.
• Solar inverter and battery logger over RS485: rooftop solar is everywhere now, and most owners have no idea how their system is performing.

You can filter the full library by domain, for example AI and ML ideas, web ideas or IoT ideas, and by beginner or advanced difficulty.

How to turn an idea into a proposal your supervisor approves

Once you have a shortlist of two or three, do this before the proposal meeting:

1. Talk to five potential users. Ask how they solve the problem today, what it costs them, and what they would pay attention to. Write down quotes.
2. Write a one page scope. Must-have features (four to six), nice-to-have features, and a "won't do" list. The "won't do" list is what convinces a supervisor you can finish.
3. Sketch the architecture. Boxes and arrows: clients, API, database, any external services. Name the riskiest part.
4. Plan the first slice. Which single feature will work end to end by the FYP-I evaluation?
5. Split ownership. Who owns which feature, end to end.
6. Check funding. Ignite (the National Technology Fund) has run a grassroots FYP funding programme for final year ICT students. Check its site for this year's cycle and eligibility, especially if your project needs hardware.

If you want to discuss an idea before committing, Sefism members can do that on the FYP ideas discussion page: share the problem, your scope and your team size, and get honest feedback on whether it will finish.

What to learn alongside your FYP

Your FYP should pull your learning, not the other way round. A few pairings that work well:

• Building a web app: follow the full stack roadmap or the backend roadmap, and keep the backend cheat sheet open.
• Building an AI feature: the AI engineering roadmap puts retrieval, evaluation and agents in a sensible order, and the AI engineering cheat sheet covers the terms examiners will ask about. Grokking Modern AI Fundamentals is a good structured start.
• Designing the data model: Grokking Relational Database Design and Modeling will save you from the classic FYP schema that falls apart in FYP-II.
• Getting ready for the job search that starts right after: the job-ready roadmap for final year students.

My honest read

The FYP that gets you hired is rarely the most ambitious one. It is the one that is finished, deployed, used by real people, and explained clearly by every member of the team. A modest tuition centre manager with thirty real users, clean code, tests and a thoughtful report beats an "AI-powered smart city platform" that only works in the demo.

Pick a real problem. Cut the scope until it scares you a little. Own one part of it end to end. Then write down every decision, because a year from now an interviewer is going to ask you why.

FAQ

What are good FYP ideas for BSCS students in 2026?

Ideas that solve a real problem for users you can reach: small business tools (ledgers, reconciliation, COD), AI projects where the hard part is the data or language (Roman Urdu triage, retrieval over real documents), and tightly scoped IoT. Browse scoped ideas in the Sefism FYP library.

Are AI FYP ideas better for getting a job?

Only if the AI part is real engineering: evaluation, retrieval, guardrails, cost and latency. A chatbot wrapper does not stand out. A well built non-AI project with real users often does better in interviews.

How many features should an FYP have?

Four to six must-have features is plenty for a team of three over two semesters. Finish those properly, with tests and real users, before adding anything else.

What do recruiters ask about final year projects?

The problem and users, the architecture and why you chose it, the hardest bug, your own contribution, what would break at scale, and what you would change. Prepare real answers to all six.

Should software engineering students choose a different FYP from CS students?

Not necessarily. BSSE groups can lean more into process: requirements, testing, CI and documentation. The same idea works for both if the scope and evidence fit your programme.

Ask your own question

If your question about choosing or scoping an FYP is not answered here, browse the career questions library, where real questions from students are answered in full.

Want a learning roadmap built around you, written answers to your own questions and a place to discuss your FYP? Create your free Sefism account. Members can also book a one to one session when they want to talk it through.

Stay in touch

• LinkedIn: where I share roadmaps, career advice and honest takes on hiring. Follow, or message me.
• X (Twitter): short practical thoughts on engineering and careers.
• Instagram: quick tips and a more personal side.
• Sefism Discord: find FYP teammates and get feedback on your idea from students who have just been through it.
• Sefism on YouTube: walkthroughs and talks.

Cover photo by Vitaly Gariev on Unsplash