The best FYP ideas for software engineering students are projects where the engineering process is visible: clear requirements, a deliberate architecture, automated tests and a working deployment. Below are 22 BSSE project ideas built around that, from developer tools to multi-tenant systems, each with a tech stack and a difficulty level.
Looking for computer science ideas instead? See our 70 FYP ideas for CS students, or use the FYP idea generator to filter ideas by your group’s skills.
Jump to: Developer tools · Testing and DevOps · Architecture-heavy systems · SE with AI · What examiners check · FAQ
How a software engineering FYP differs from a CS FYP
Both degrees build software, but the projects are usually judged differently. A BSCS project is often graded on how hard the problem or algorithm is. A BSSE project is graded on how well you engineered the solution. Rubrics vary by university, so check yours, but the difference usually looks like this:
| Aspect | Typical BSCS FYP | Typical BSSE FYP |
|---|---|---|
| Main question | Can you solve a hard problem? | Can you build a reliable system the right way? |
| What earns marks | Algorithm, model, novelty | Requirements, design, testing, process |
| Key documents | Report on approach and results | SRS, design document, test plan, user manual |
| Evidence | Accuracy, benchmarks, demo | Requirements traced to tests, version history, sprint records |
| Good project types | AI models, research prototypes | Platforms, developer tools, systems with many users and roles |
That is why a plain CRUD app is a weak BSSE project: there is no engineering decision to defend. Pick an idea where you can show why you chose an architecture, how you tested it and how you managed the work.
Developer tools and process automation FYP ideas
These projects build tools for other developers. Examiners like them because the problem itself is a software engineering problem.
| # | Idea | What it does | Tech stack | Difficulty |
|---|---|---|---|---|
| 1 | Requirements ambiguity checker | Scans an SRS for vague words like “fast” or “user-friendly”, flags them and suggests measurable rewrites | Python, spaCy, React | Medium |
| 2 | UML generator from source code | Reads a Java or TypeScript repository and generates class and sequence diagrams that stay in sync with the code | Java parser or ts-morph, PlantUML, Node.js | Medium |
| 3 | Test case generator from user stories | Turns user stories written as Given/When/Then into test cases and Playwright test skeletons | Node.js, LLM API, Playwright | Medium |
| 4 | Technical debt dashboard | Tracks code smells, duplication and outdated dependencies per sprint and shows whether debt is going up or down | ESLint or SonarQube API, Node.js, Chart.js | Medium |
| 5 | Merge conflict early warning | Warns developers when two open branches change the same files or functions, before anyone merges | GitHub API, Python, Git | Hard |
| 6 | Sprint estimation assistant | Learns from a team’s past story points and actual hours to suggest estimates for new tasks | Python, scikit-learn, React, Jira or Trello API | Medium |
Related: Software requirements document checklist · Agile vs waterfall
Testing, quality and DevOps FYP ideas
Testing projects are rare in student portfolios, which makes them stand out in job interviews as well as in the viva.
| # | Idea | What it does | Tech stack | Difficulty |
|---|---|---|---|---|
| 7 | Visual regression testing tool | Screenshots a web app before and after each deployment and highlights layout changes pixel by pixel | Playwright, pixelmatch, Node.js | Medium |
| 8 | API contract testing service | Checks a live API against its OpenAPI spec in CI and blocks merges that would break the mobile app or other clients | Node.js, OpenAPI, GitHub Actions | Medium |
| 9 | Self-hosted CI for department labs | Builds and tests student repositories on every push and shows the results on a dashboard for the lab instructor | Docker, GitHub webhooks, Go or Node.js | Hard |
| 10 | Feature flag and gradual rollout platform | Switches a feature on for a small share of users, one city or internal staff only, without a redeploy | Node.js, Redis, React SDK | Medium |
| 11 | Load testing and performance reports | Records real user flows, replays them as load tests and reports response times and the point where the system breaks | k6, Grafana, Node.js | Medium |
| 12 | Web accessibility auditor | Checks pages against WCAG guidelines and produces a fix list with screenshots, useful for university and public-service websites | axe-core, Puppeteer, React | Easy |
Related: QA automation engineer roadmap
Architecture-heavy system FYP ideas
These are full systems where the interesting part is the design: services, events, tenants and sync. Draw the architecture early, because your viva will be about the decisions behind it.
| # | Idea | What it does | Tech stack | Difficulty |
|---|---|---|---|---|
| 13 | Microservices admission portal | Separate services for applications, fee vouchers and merit lists that talk through a message queue, so one failing service does not stop the rest | NestJS or Spring Boot, RabbitMQ, Docker | Hard |
| 14 | Multi-tenant SaaS for coaching academies | One codebase serving many academies, each with its own students, fees, attendance and test results, kept strictly separate | Laravel or Node.js, PostgreSQL row-level security | Hard |
| 15 | Offline-first billing app with sync conflicts | Shop billing that keeps working without internet and merges sales from several devices when the connection returns | Flutter, SQLite, Supabase or Firebase | Medium |
| 16 | Event-sourced inventory system | Stores every stock movement as an event, so you can rebuild stock levels on any past date and audit every change | Node.js or .NET, PostgreSQL | Hard |
| 17 | University bus tracking with live ETAs | Drivers share their location from a phone app and students see where the bus is and when it will reach their stop | Flutter, Node.js, Socket.IO, maps API | Medium |
| 18 | Plugin-based learning management system | A small LMS core with plugins for quizzes, attendance and plagiarism checks that can be added or removed without touching the core | React, NestJS, PostgreSQL | Hard |
Related: MERN stack internship · Full stack development internship
Software engineering + AI FYP ideas
AI is now part of everyday development work. These ideas use it to improve the software process, which keeps the project in software engineering territory.
| # | Idea | What it does | Tech stack | Difficulty |
|---|---|---|---|---|
| 19 | Bug report triage bot | Labels new GitHub issues by component and severity and points out likely duplicates of older issues | Python, sentence embeddings, GitHub API | Medium |
| 20 | Legacy code documentation assistant | Reads an undocumented PHP or Java codebase and writes module summaries, API docs and diagrams for new developers | tree-sitter, LLM API, Node.js | Medium |
| 21 | Commit message and changelog generator | Suggests clear commit messages from staged changes and builds release notes from merged pull requests | Node.js, Git hooks, LLM API | Easy |
| 22 | Requirements-to-prototype generator | Turns a short requirements description into clickable wireframes the team can review before writing code | React, LLM API | Hard |
What examiners check in a BSSE FYP
Rubrics differ between universities, but software engineering panels usually look for the same evidence. Plan for it from week one instead of writing it up at the end.
- Requirements you can trace. Every functional requirement in your SRS should map to a design element and at least one test case.
- Design decisions with reasons. Class diagrams, an ERD and an architecture diagram that match the code, plus a short note on why you chose this design over an alternative.
- A real test plan. Unit, integration and a few end-to-end tests, with results you can show in the report.
- Process evidence. Sprint plans, a task board and a commit history where every member’s work is visible.
- A working deployment. A live link or a reliable local setup, so the demo does not depend on luck.
Our guides on the FYP proposal, FYP documentation and viva questions cover each of these in detail.
Common mistakes BSSE groups make
- Choosing a CRUD app with nothing to engineer, then trying to make it look complex in the report.
- Writing the SRS after the code, so the requirements and the features do not match.
- Leaving testing for the last two weeks.
- One member writing all the code, which shows quickly in the commit history and in the viva.
- Drawing diagrams once and never updating them as the design changes.
Frequently asked questions
What is a good FYP idea for software engineering students?
A good BSSE idea has a clear user, enough scope for every group member to own a module, and real engineering decisions to defend, such as the architecture, the testing strategy or syncing data between devices. Developer tools, testing platforms and multi-tenant systems work well because the engineering is the point of the project.
What is the difference between a BSCS and a BSSE final year project?
A BSCS project is usually judged on how hard the problem is, while a BSSE project is judged on how well the system is engineered: requirements, design, testing and process. Both can use the same technologies; the documents and evidence you present are what differ.
Which methodology should a software engineering FYP follow?
Most groups use a lightweight Scrum: two-week sprints, a task board and a short review at the end of each sprint. Whatever you choose, keep records of sprints and decisions, because examiners often ask how you managed the work.
Can a software engineering FYP use AI?
Yes, as long as software engineering stays at the centre. A bug triage bot or a test case generator uses AI to improve the development process, which fits a BSSE project better than training a model for its own sake.
How many modules should a BSSE FYP have?
There is no fixed number; it depends on your university and group size. A useful rule is that each member owns at least one module end to end, from requirements to tests, so everyone can answer questions on their part in the viva.
Turn the idea into a finished project
Most groups do not get stuck on the idea. They get stuck building it on time, next to exams. How Ezitech can help:
- Build it yourself with mentors: an Ezitech internship puts you on hands-on projects in the same stacks these ideas use, such as MERN and full stack development.
FYP ideas by degree: Software engineering · AI · Cyber security · IT · Computer science (70 ideas)
More FYP help: FYP idea generator · FYP proposal format · FYP documentation · FYP viva questions