15 Software Engineering Capstone Project Ideas

Choose a capstone you can build, test and explain. These software engineering capstone project ideas cover development tools and reliable campus workflows, with suggested stacks, a manageable first release and a demonstration target for each.

Compare the options, then confirm your scope and assessment requirements with your faculty guide.

Jump to: Compare projects · Project briefs · Choose a topic · FAQs

What is a software engineering capstone project?

A software engineering capstone applies requirements analysis, design, implementation and testing to a defined problem. It produces working software and evidence explaining whether the intended behavior was achieved. Required deliverables, such as a software requirements specification (SRS), diagrams and a report, depend on your institution.

The minimum viable product (MVP) is the smallest usable release that completes the central workflow. For an asset system, that might mean requesting, issuing and returning one equipment unit.

Test fixtures are prepared records, files or other inputs used to create a repeatable starting point for a test. A sample event with one remaining seat is a fixture for testing registration behavior.

For broader AI, data and application domains, explore FileMakr’s computer science capstone project ideas. This guide focuses on requirements, software quality and reliable workflows.

Compare 15 ideas by difficulty, stack and demonstration

Difficulty assumes basic familiarity with the suggested technology. MERN means MongoDB, Express, React and Node.js. API means application programming interface.

The stacks below are suggestions. They do not indicate that every proposed system is available as a FileMakr product.

Project briefs: what to build and demonstrate

1. Bug and issue tracker

Developers report issues, while a maintainer assigns them and controls transitions such as open, in progress and closed.

Build one project space, issue descriptions, priorities, assignment and status history. The output is a current issue list with an attributable record of changes.

Demonstration: attempt to reopen a closed issue using an account without permission. The server should reject the action, even if someone bypasses the interface.

Keep chat, time tracking and multiple organizations outside the first release.

2. Requirements traceability tool

An analyst records requirements, developers link implementation tasks, and testers associate acceptance checks.

Start with requirement versions, task links, test definitions and execution records. Display requirements without linked tests and requirements whose latest versions need evidence review.

For example, requirement R-03 may state that only an assigned reviewer can approve a document version. Link R-03 version 2 to its permission tests, implementation commit and test run. If version 3 changes the approval rule, flag the earlier evidence for review.

Demonstration: change a requirement and verify that evidence for its previous version is not automatically treated as current.

A requirement linked to a test has planned coverage; it does not establish that the test was executed or passed. Keep linked, executed, passed and reviewed states distinct.

3. Test case management system

Testers create cases, organize runs and record passed, failed, blocked or unexecuted outcomes. A release lead views totals and individual results.

Build test definitions, execution records, result summaries and a basic release history.

Demonstration: reconcile dashboard totals with individual execution records. Updating a test definition must not silently rewrite an earlier completed run.

Preserve the case version or a snapshot used during execution. Manual result recording is sufficient initially; automated test-runner integration can follow later.

4. CI build results dashboard

Continuous integration (CI) checks integrated code through automated workflows. GitHub Actions is one platform that can automate builds, tests and deployment.

Build a dashboard that imports prepared JSON or XML reports and displays run identifiers, software commits, execution times and failures.

Demonstration: importing the same run twice should not create duplicate records. A malformed report should produce a clear error without leaving a partially imported run.

File import provides a manageable MVP without repository credentials or live integration.

5. Code review workflow portal

Authors submit prepared code changes. Reviewers comment, request revisions and approve a particular revision.

Build submission records, revision history, reviewer assignments and review decisions. The output is a clear review status for each submitted revision.

Demonstration: upload a new revision after approval. Under the application’s policy, the new revision should require fresh review.

Associate comments with the revision they describe. Live repository synchronization and execution of submitted code can remain outside the initial scope.

6. Change impact analyzer

Accept source files in one language and analyze a documented subset of import statements. Show modules that may be affected when a selected module changes.

Build file import, dependency extraction, graph traversal and a report explaining the result.

Demonstration: compare the analyzer’s output with a manually checked dependency graph. Count correctly identified, missed and extra modules. Include examples involving shared dependencies and cycles.

State unsupported constructs, such as dynamic imports outside the analyzer’s rules. A dependency connection indicates possible impact; it does not prove that a module or its tests will fail.

7. Feature flag configuration simulator

An administrator defines feature rules. A tester enters a synthetic account identifier and receives an enabled or disabled result, together with the matched rule.

Build configuration versions, rule precedence, percentage groups and rollback.

Demonstration: identical inputs and configuration should produce the same assignment. Use a stable assignment method instead of generating a fresh random result on every request.

Define what happens when rules overlap or an account matches none. Keep the first release a simulator without a production traffic dependency.

8. Offline campus maintenance desk

Maintenance staff record ticket updates without connectivity and synchronize them later. IndexedDB, a browser database, can store pending operations locally.

Begin with one ticket type, a unique identifier for each operation and a server-side record version.

If the server saves an update but its response is lost, the client cannot assume the update failed. Retrying with the same operation identifier must not apply the change again. Persist the identifier and update atomically—so both are saved together or neither is—and enforce uniqueness within the identifier’s defined scope.

AWS’s Making retries safe with idempotent APIs explains how request identifiers and atomic recording of changes support safe retries.

Demonstration: simulate a lost response after saving an update, then retry it. Verify that only one change was applied.

Also test two devices editing the same ticket version. Surface a conflict and apply a documented resolution rule rather than silently discarding an update.

9. College event registration and waitlist

Students register for an event, while a coordinator sets capacity and manages cancellations.

Build one registration per student per event, confirmed and waitlisted states, cancellations and ordered promotion. The output is a registration status and coordinator list.

Define the main rule: confirmed registrations must never exceed capacity.

Demonstration: submit two overlapping requests when one seat remains. At most one may be confirmed; the other follows the waitlist rule. Cancel a confirmed place and verify that only one eligible waiting student is promoted.

For PostgreSQL, one design locks the shared event row inside a transaction before checking and allocating capacity. Registration, cancellation and promotion must follow compatible coordination rules. The PostgreSQL locking documentation explains the mechanism.

Add a database uniqueness rule for the event-and-student combination. Save request identifiers, evidence of overlapping execution and the final database state. Exclude payments and complex scheduling initially.

10. Lab asset checkout system

Students request equipment, while a lab assistant approves, issues and receives individual units.

Record each unit’s identifier, condition and availability, including maintenance status. Distinguish an approved reservation from physical collection.

Demonstration: an asset under repair must not be issued. Two overlapping issue requests must not assign the same unit twice.

Use synthetic borrower records for evaluation. Begin with one lab and a small equipment catalog; QR scanning and procurement can be later extensions.

11. Document approval system

Submitters upload documents, and assigned reviewers approve or reject specific versions.

Build document versions, reviewer assignments, decisions and review history.

Demonstration: approval of version 1 must not automatically approve version 2. An unauthorized account sending a direct approval request should be denied.

Approval records should identify the document version reviewed. An earlier approval does not establish review of a later revision.

A single-reviewer workflow is sufficient for the first release. Parallel committees introduce additional rules for quorum, rejection and resubmission.

12. API contract regression tester

Developers define requests and expected status codes, required fields and response types for a local sample API.

Run the checks against two application versions and display detected differences.

Demonstration: deliberately remove a required response field in the second version. The corresponding assertion should fail and identify the missing field.

Preserve the request fixture, response and assertion. Prefer explicit interface expectations over comparisons that fail whenever harmless timestamps change.

This project evaluates defined interface behavior; it does not establish complete application correctness or security.

13. Accessible student services portal

Build a small portal containing notices and a service-request form.

Test keyboard operation, visible focus, meaningful labels and understandable validation feedback. W3C provides direct explanations of Keyboard, criterion 2.1.1, and Error Identification, criterion 3.3.1.

Demonstration: complete the main form using a keyboard, submit invalid input and identify which field needs correction.

Record the criteria, browsers and assistive tools actually evaluated. Successful checks on a few criteria do not establish whole-site WCAG conformance.

Keep the portal small enough to evaluate its complete main workflow.

14. Legacy module refactoring study

Choose a small module that you can legally use and understand. Add characterization tests that record its existing behavior before restructuring it.

Separate mixed responsibilities or duplicated logic, then compare behavior using the same fixtures.

Demonstration: the documented behavior should remain consistent after refactoring. Explain whether an existing bug is deliberately preserved or changed separately.

Report a defined structural measure where useful. Claim faster execution only after a controlled performance comparison. Avoid replacing an entire application when one module provides a clearer study.

15. Flaky test analysis tool

Import repeated test results with test identifiers, application and test-code versions, input references and environment details.

Compare repeated runs of the same test using the same versions and inputs under documented, sufficiently controlled conditions. Group results by version and environment so intentional changes are not automatically labeled as flaky behavior.

The pytest documentation on flaky tests discusses intermittent failures and problems involving uncontrolled state or insufficient isolation.

Demonstration: evaluate against deliberately stable and unstable examples. Record rerun counts and pass/fail outcomes. Investigate order-dependent failures through a separate experiment that documents the order being varied.

Distinguish consistently failing tests from intermittent failures. Flag incomplete or incomparable records for review. Observed instability does not establish its cause without further investigation.

How to choose a project you can finish

Compare candidates on five criteria:

1. Availability of realistic test fixtures.
2. Familiarity with the implementation stack.
3. Clarity of the MVP.
4. Ability to test difficult behavior.
5. Fit with your available time.

Score each criterion from 0 to 2: unresolved, partly resolved or clear. Confirm mandatory college requirements before comparing totals.

Illustrative example: a solo student knows PHP forms and basic database operations, has synthetic inventory records and has not implemented offline storage. Their department permits individual work.

These are example planning judgments, not measured difficulty or a validated grading scale.

Asset checkout is the stronger initial choice for this profile because offline maintenance introduces unfamiliar retry and conflict behavior. Another student’s experience could change the result.

After choosing the workflow, explore relevant Node.js project resources or Python project resources. Check each resource’s actual features, dependencies and setup requirements.

A requirement-to-test example

This document-approval walkthrough describes expected behavior, not executed results.

Requirement R-03, version 2: only the reviewer assigned to a document version may approve it.

Create reviewer accounts A and B. Assign A to document version 2. Under this application’s policy, version 3 requires a fresh decision.

Link the requirement version, implementation commit and test-run identifier. Record actual outcomes separately, including any mismatch with expectations.

A screenshot can support the explanation. Saved inputs, responses and resulting records make the behavior easier to reproduce and inspect.

An illustrative eight-week implementation plan

Adjust this schedule to your academic calendar, skills and required deliverables. For event registration, the milestones could be:

1. Week 1: agree the scope. Define student and coordinator roles, capacity rules and waitlist promotion. Produce a synopsis and observable acceptance criteria.
2. Week 2: design the workflow. Model states, permissions and data relationships. Produce an SRS and diagrams matching the intended implementation. Apply software design patterns for final-year projects where they solve a stated problem.
3. Weeks 3–4: complete one workflow. Connect event creation, registration and status display. Produce a working interface-to-database demonstration before optional modules.
4. Weeks 5–6: exercise important failures. Test overlapping requests, repeated submissions, cancellations and unauthorized actions. Record expected and actual results. The OWASP Web Security Testing Guide provides a reference for planning relevant web-security checks; record the release used.
5. Week 7: make setup repeatable. Record dependency versions, configuration and fixture-loading instructions. Produce a README another team member can follow, with secrets kept outside shared examples.
6. Week 8: align the submission. Check the report, diagrams and screenshots against the final software. Prepare a demonstration script, limitations and individual contribution notes.

Common mistakes and practical improvements

• Adding unrelated modules: chat, payments and recommendations can delay the central workflow. Freeze the MVP acceptance criteria and keep extensions in a separate list.

• Testing only through the interface: hiding a button does not establish authorization. Send a direct request from an account without permission and inspect the result.

• Treating one successful run as proof: a capacity bug may require overlapping requests. Document how overlap was created and preserve the failing case for regression checks.

• Combining incomparable test results: different code versions, inputs or environments can explain different outcomes. Separate these groups before investigating instability.

• Claiming broad quality from narrow evidence: contract checks do not establish complete security, accessibility or scalability. State exactly what was evaluated.

• Reusing unexplained code: record licences, attribute sources, follow college rules and explain your own implemented contribution.

Practical tips: prefer a simple deployment unless distributed components are part of the question being evaluated. Preserve historical requirement and test versions. Reset fixtures between experiments unless shared state is the specific condition under investigation.

Software engineering capstone FAQs

Which software engineering capstone projects are suitable for beginners?

A bug tracker or lab asset checkout system is a practical starting point if you know forms, authentication and database operations. Begin with one team or lab and one complete workflow. Add advanced features after validation and permissions work.

Can I build a capstone alone?

Yes, if your institution permits individual projects and the scope fits your skills and time. A small issue tracker, asset checkout system or local API tester can support a solo project. Confirm required deliverables before committing.

Does a software engineering capstone need AI?

No. Traceability, regression testing, refactoring and reliable workflows demonstrate software engineering without AI. Include AI when it solves a defined problem and you can evaluate its outputs.

Can I avoid paid APIs?

Yes. Bug tracking, asset checkout, document approval and local API testing can use synthetic records or software you control. Imported reports can support a CI dashboard. Hosting and optional development tools may still have costs.

How many students should work on the project?

Follow your department’s team-size rules. Allocate ownership of complete workflows, with shared integration and review checkpoints. Keep individual contribution records; a larger team does not automatically justify more modules.

How should I test my final-year project?

Convert acceptance criteria into repeatable checks for successful behavior, invalid input, permissions and relevant failures. Record fixtures, environment, software version, expected results and actual outcomes. Repeat affected checks after changes.

How can I show originality in a familiar topic?

Describe the problem, baseline limitation, your change and its evaluation. An event system might focus on correct final-seat allocation. Attribute reused components and separate your contribution from existing code. Agree formal research novelty requirements with your guide.

What should I prepare for the viva?

Prepare the problem statement, architecture, data model, core demonstration, test evidence and limitations. Explain one design tradeoff, one bug you investigated and the code you implemented or adapted yourself.

Choose your topic and define the first demonstration

Shortlist three ideas and define one complete workflow for each. Choose the option whose inputs, expected behavior and evaluation you can explain clearly, then confirm the scope with your guide.

Explore FileMakr’s project resources for relevant implementation references. Compare features, dependencies and setup instructions, then adapt and evaluate your work according to your college’s requirements.