FYP Ideas for Software Engineering (2026): Final Year Projects That Show Engineering Skill

A software engineering FYP panel has seen a hundred working apps. What it has seen far fewer of is a group that can show where each requirement came from, why the architecture looks the way it does, and which tests would fail if someone broke the checkout flow tomorrow.

That is the gap this post is about. For a BS Software Engineering student, the idea matters less than the evidence of engineering around it: requirements, design decisions, tests, a pipeline and documentation a stranger can follow.

Below are 20 final year project ideas for software engineering chosen because each one gives you room to show that process, plus a table of which skills each idea proves. For a broader list across AI, web and mobile, see our 32 FYP ideas for computer science.

What software engineering panels look for

A software engineering panel marks the process as much as the product: how you gathered requirements, designed the system, tested it, delivered it and documented it.

That is what the discipline is. The IEEE Computer Society's SWEBOK Guide v4.0 lists 18 knowledge areas, and version 4 added Software Architecture, Software Engineering Operations and Software Security as areas of their own. Your project is the place to show several of them working together.

In practice, examiners look for:

• Traceable requirements. Each feature maps back to a stated user need, and each requirement has an acceptance test.
• Deliberate architecture. Diagrams at more than one level, and written reasons for the big choices.
• Automated tests at several levels. Unit, integration and end-to-end, run on every change, not once before the viva.
• A delivery pipeline. Code goes from commit to a running environment without manual copying.
• A clean history. Small commits, reviewed pull requests, tagged releases.

A working app with none of this reads as a CS project. The same app with all of it reads as engineering.

The evidence pack every SE project needs

Whatever idea you pick, plan these artefacts from week one. They become the chapters of your report, and they are what interviewers ask to see.

1. Requirements. A short SRS with user stories and acceptance criteria. Your department may have a template; the FYP proposal guide covers the proposal end.
2. Architecture. Context, container and component diagrams using the C4 model, plus an architecture decision record for each big choice: one page on what you chose, the alternatives and the trade-off.
3. API contract. If there is a backend, describe it in OpenAPI, the vendor-neutral format for HTTP APIs, before you build the client.
4. Tests. Unit tests for logic, integration tests against a real database (with Testcontainers), and a few end-to-end tests of the main user journeys with Playwright.
5. CI/CD. A GitHub Actions workflow that runs linting and tests on every pull request and deploys the main branch. Standard GitHub-hosted runners are free for public repositories (GitHub billing docs).
6. Documentation. A README that gets a new developer running in ten minutes, a user manual with screenshots, and release notes. Conventional Commits make the history readable and the notes easy to generate.

Add static analysis with the free SonarQube Community Build and you have a quality report to put in the appendix.

SaaS and multi-tenant system ideas

Multi-tenant systems force real design decisions: how tenants are separated, how roles work, how one customer's data never leaks into another's.

• 1. Multi-clinic appointment SaaS. Many clinics on one deployment, each with its own doctors, slots and patients. Enforce isolation in the database with PostgreSQL row-level security and write tests that try to read another clinic's rows. Shows: security requirements, data architecture, negative testing.
• 2. Academy fee and subscription billing. Monthly plans, invoices, overdue reminders and a ledger that always balances. Use a payment provider's sandbox only. Shows: domain modelling, state machines, property-based tests for money.
• 3. Feature-flag service. A small service plus a client SDK that turns features on for some users or a percentage, with an audit log of who changed what. Shows: API design, SDK versioning with semantic versions, backward compatibility.
• 4. Multi-branch inventory SaaS. Stock across shops of one business, transfers between branches and low-stock alerts. Shows: concurrency, transactions, role-based access.

Microservices and backend architecture ideas

Choose microservices only if you can justify them in an ADR. A panel will ask why the system is not a single well-structured app, and "because it is modern" is the wrong answer.

• 5. Order, inventory and notification services. A grocery order system split into three services that talk through RabbitMQ. Use Pact contract tests so each service can change without breaking the others. Shows: service boundaries, messaging, contract testing.
• 6. Event ticketing with seat holds. Hundreds of buyers want the same seats at once; seats are held for ten minutes, then released. Prove it holds up with a k6 load test. Shows: concurrency control, performance requirements, load testing.
• 7. Exam result publishing service. A modular monolith that imports marks, applies grading rules, and publishes results with an audit trail of every change. Shows: business-rule testing, auditability, modular design.

Mobile and backend project ideas

A mobile project becomes an SE project when the hard parts are on both sides: offline behaviour, sync, versioned APIs and releases.

• 8. Offline-first delivery rider app. Riders see their drops, mark them delivered without signal, and sync later. Define and test what happens when two devices edit the same order. Shows: sync design, conflict resolution, API versioning.
• 9. Pharmacy stock app with barcode scanning. Staff scan items in and out; the backend tracks batches and expiry dates. Shows: domain rules, integration tests, mobile release process.
• 10. Garage job-card system. A mechanic logs work and parts on a phone; the front desk prints the bill and the customer gets status updates. Shows: requirements from interviews, workflow states, usability testing.

DevOps and testing tool ideas

Tools for developers are a strong SE choice: your users are developers, and your own pipeline is part of the demo.

• 11. Mini deployment platform. Push to a repository, the platform builds a container with Docker Compose, runs health checks, and rolls back automatically if the new version fails. Shows: release engineering, twelve-factor configuration, failure handling.
• 12. Uptime monitor and status page. Checks sites and APIs, records response times, alerts by email or WhatsApp and publishes a status page. Expose metrics for Prometheus and traces with OpenTelemetry. Shows: observability, reliability requirements.
• 13. Flaky test detector. Collects CI results across runs, finds tests that pass and fail on the same code, and opens an issue with the evidence. Shows: data from pipelines, GitHub API integration.
• 14. Mutation testing dashboard. Runs Stryker on student repositories and shows which tests would not catch a deliberately broken line. Shows: test quality, not just coverage.
• 15. API breaking-change checker. Compares two versions of an OpenAPI file and fails a pull request if a change would break existing clients. Shows: contracts, CI gates, versioning policy.
• 16. Visual regression service. Takes screenshots of key pages on every pull request with Playwright's screenshot comparison and shows the differences to the reviewer. Shows: end-to-end testing, review workflow.

Systems for local businesses

Local systems give you the best requirements chapter: real stakeholders you can interview, observe and test with in person.

• 17. School exam and timetable system. Teachers enter marks, the system checks the grading policy, and the timetable avoids teacher and room clashes. Interview a principal before writing a single requirement. Shows: elicitation, constraint rules, acceptance testing with the school.
• 18. Clinic records with an audit trail. Patient visits, prescriptions and follow-ups, where every view and edit is logged and backups are tested by restoring them. Shows: privacy requirements, security testing with ZAP against the OWASP Top 10.
• 19. Retail POS with offline mode. Sales, returns and day-end closing that keep working when the internet drops. Pakistan's FBR already lets customers verify receipts from integrated Tier-1 retailers by invoice number or QR code (FBR); simulate that integration behind an interface rather than connecting to a live tax system. Shows: offline design, adapters, reconciliation tests.
• 20. Marble factory production tracker. Follows each block from the quarry truck through cutting, polishing and dispatch, with slab-level stock, photos and QR tags. Mardan's marble units are a short drive away for interviews. Shows: process modelling, field testing, reporting.

If you would rather build around AI, our AI and machine learning project ideas pair well with this list: add an evaluation pipeline to any of them and it becomes an SE project too.

Which idea shows which SE skill

Choose the idea whose strongest column matches the skills you want to talk about in interviews.

Idea	Requirements	Architecture	Testing	CI/CD and ops
1. Multi-clinic SaaS	Security, tenant rules	Row-level isolation	Cross-tenant negative tests	Migrations in the pipeline
5. Order services	Service contracts	Messaging, boundaries	Pact contract tests	Per-service builds
6. Ticketing	Performance targets	Locking, holds	k6 load tests	Load test as a CI job
8. Rider app	Offline scenarios	Sync design	Conflict tests	Mobile release builds
11. Deploy platform	Operator needs	Containers, health checks	Failure injection	It is the pipeline
14. Mutation dashboard	Developer users	Plugin runner	Tests of tests	Runs on pull requests
17. School system	Stakeholder interviews	Rules engine	Acceptance tests with staff	Staged releases
19. Retail POS	Day-end and returns flows	Adapters, offline queue	Reconciliation tests	Versioned updates
20. Marble tracker	Factory process mapping	Workflow states	Field testing	Backups and restore

A team of three can usually handle one of these ideas plus one stretch goal. Don't try to be strong in every column; be visibly strong in two.

Common mistakes in SE final year projects

• Writing documents after the code. An SRS written in the final month reads like a description of what was built, and examiners can tell.
• Microservices with no reason. Three services sharing one database is not a microservice architecture; it is a distributed monolith.
• Tests that only check the happy path. Test the refund, the clash, the dropped connection and the wrong user.
• One giant commit before each review. Your Git history is evidence. Commit small and often, through pull requests.
• No real users. A usability test with five real staff beats a survey of classmates.

To compare two or three shortlisted ideas, use our guide on how to choose a final year project that helps you get hired.

SE FYP FAQ

Is a software engineering FYP different from a computer science FYP?

The product can be similar; the marking usually is not. SE departments weight requirements, design, testing, project management and documentation heavily. Check your department's marking rubric early.

Do we need microservices or Kubernetes to impress the panel?

No. A well-tested modular monolith with a clear ADR explaining why it is not microservices often impresses more. Use distributed architecture only when the requirements need it.

Can we buy a project and just write the documents?

No. Buying or outsourcing an FYP is academic misconduct, and in an SE viva it shows fast: the panel asks why a design decision was made or what a test covers. Get guidance, then build and document it yourselves.

Key takeaways

• SE panels mark the process: requirements, architecture, testing, delivery and documentation.
• Plan the evidence pack from week one: SRS, C4 diagrams, ADRs, an API contract, tests, a pipeline and a README.
• Pick an idea with real stakeholders or real developer users you can test with.
• Justify architecture choices in writing; microservices need a reason.
• Be visibly strong in two skill areas rather than thin in all of them.
• Build it yourselves; never buy a project.

Get mentorship for your SE project

Softhat mentors final-year software engineering students at our Mardan, Khyber Pakhtunkhwa office or remotely: scoping requirements, reviewing architecture and ADRs, setting up tests and CI/CD, code reviews and viva practice. Your team writes the code and the documents; we help you engineer them properly. See FYP mentorship, learn the stack in our web development course, or look at the web designing internship after graduation.

Ask about FYP mentorship