Final-year project: build evidence, not just a demo
Build a final-year project you can explain and hand over: task planning, team Git workflow, useful sync-ups, risk-based testing, CI and practical evidence templates.
This is a suggested CSE-Pothik quality bar—not a university rule, accreditation or certification. Your department rubric, supervisor and ethics/safety requirements take priority. Reduce the scope, not the evidence.
If you feel behind, do not rewrite everything. Pick one core journey, name its risks, fix a failure and let someone else run it. Small work you can explain is strong portfolio evidence.
Working habits: small team, clear flow
You do not need to read everything now. Choose the job you are tackling today; each playbook has steps and a worked example.
01 · Before the first feature
Agree how the team will work
Start with one useful outcome, realistic availability and a shared agreement. A student team needs clarity, not a miniature corporate bureaucracy.
How to do it & worked example: Agree how the team will work
Write a one-page agreement
Record the rubric, deadline, weekly hours around classes/exams, communication channel, response window and supervisor review dates. Agree how to raise concerns, handle absences and credit contributions. Do not rank people by commit counts.
Share ownership, rotate responsibilities
Give every issue one owner and a different reviewer. Rotate meeting facilitation, release coordination and quality checks; QA is everyone’s responsibility. Pair on risky work so no critical module is understood by only one person. Solo students can arrange milestone reviews with a peer or supervisor.
Plan backward from evidence
Agree a small end-to-end milestone, then work in one-week iterations. Reserve time for review, testing, integration and exams. Keep a risk list with owner, early warning and fallback. If access to data or hardware is uncertain, investigate that first, before promising features.
Trade scope, not sleep or evidence
When new work appears, record its benefit, cost and risk; exchange it for a lower-priority item with the team and supervisor. Keep a visible cut list. Freeze nonessential features before the submission buffer; do not postpone all testing or the report to the last week.
Example: a 12-week window, not a prescribed schedule
Weeks 1–2: validate the problem, permissions, brief and repo; investigate the biggest risk. Weeks 3–4: demo one tested vertical slice.
Weeks 5–8: add only core slices with review and tests each week. Weeks 9–10: integrate, evaluate, repair and rehearse recovery; freeze new scope.
Weeks 11–12: independent clean setup, final evidence, report and defense rehearsal. Write the report throughout. Resize this example to your actual semester and approvals.
Use one shared task manager as the source of truth. Track outcomes and evidence—not a board full of vague cards such as “do frontend”.
How to do it & worked example: Turn an idea into small, testable tasks
Set up a small board
GitHub Projects beside GitHub Issues is a convenient starting point; an existing Trello, Jira or other shared board is fine too. Create Status, Owner, Priority, Milestone and Estimate fields; use labels or the issue body for risk and dependencies. Keep one record per task and link the repository instead of duplicating status in chat.
Split by usable behavior
Outcome → milestone → user-visible slice → implementation and test tasks. A slice crosses UI, logic and data to deliver one small behavior; separate specialists can own its subtasks. Aim for roughly half a day to two days of focused work per task. If you cannot estimate a risk, create a time-boxed research spike with a question, experiment and decision—not an endless “research” card.
Define Ready and Done
Ready means the problem, owner, acceptance criteria, dependencies and test approach are understood. Done means reviewed and merged code, passing relevant tests, verified acceptance criteria, updated docs and linked evidence. “It works on my laptop” and “PR merged” alone are not Done. If an issue auto-closes on merge, keep its verification status separate or complete verification before merging.
Keep flow honest
Backlog → Ready → In progress → In review → Verify → Done. Mark blocked work with the reason, helper and next check-in; do not hide it in Done. Start with one active implementation task per person. Review waiting work before starting more. A failed acceptance check returns to In progress with a reproducible defect; adjust estimates using actual experience, not pressure.
Worked task: prevent a double booking
Outcome: reliable equipment booking. Milestone: one equipment type can be booked safely. Slice: REQ-01 rejects overlapping reservations, including simultaneous requests.
Issue #42: enforce atomic conflict protection. Owner: one implementer; reviewer: another teammate. Dependency: agreed time-zone and interval rules. Estimate: one focused day plus review; re-estimate after the database spike if needed.
AC-01: for two valid concurrent requests for the same slot, one succeeds, one gets a clear conflict, and exactly one booking remains. Tasks: prove the database rule, implement it with an integration test, then connect the accessible conflict message as the next linked task. Evidence: ADR-01 → PR #43 → TEST-01 log.
Git records local history; a hosted repository lets the team collaborate and recover shared work. Start with the brief and setup instructions, not the night before submission.
How to do it & worked example: Start version control on day one
Create one shared home
A maintainer creates the repository, invites teammates using individual accounts and gives only necessary permissions. Choose visibility with the supervisor and data owner; public is not automatically appropriate. Enable account protection. Others clone that repository; do not exchange project ZIPs or create unrelated copies as the collaboration workflow.
Make the first commit useful
Include a README with purpose, prerequisites and exact setup/test commands; a stack-specific ignore file; a safe .env.example; the package lockfile; and a contribution guide describing branches and reviews. Record licensing with the rights holder. Do not add a license to borrowed work you do not own. Commit small logical changes after checking the diff; push regularly so local history is not your only copy.
Organize for the chosen stack
Keep application source, tests, documentation, automation and configuration distinguishable. Follow your framework’s conventions before inventing layers. A web app may use src/, tests/, docs/, scripts/ and .github/workflows/; a research project may also need reproducible experiment configs and data manifests. Version migrations and safe sample data, not live database dumps or generated dependency/build folders.
Protect data and recoverability
Keep passwords, tokens, personal records and unapproved datasets out of Git, issues and screenshots. A private repo is not a secret vault. Store approved large artifacts separately with version/checksum and access instructions. Back up data separately from code and test restoration. If a credential leaks, revoke/rotate it promptly, notify the responsible owner and follow the host’s cleanup process; deleting the visible file is not enough.
A first-day handoff check
A teammate clones the repo into a fresh folder, follows only the README, installs locked dependencies and runs the smallest check. Record where they get stuck, repair the instructions and repeat. Agree now which folders are generated and which evidence belongs in Git.
For a small student team, prefer short-lived feature branches and a working main branch. This is a GitHub-flow-style recommendation, not a requirement for the heavier Gitflow develop/release-branch model.
How to do it & worked example: Use a simple branch → review → merge flow
Agree the main-branch rules
Keep main runnable. Where the hosting plan permits, require a pull request, at least one peer approval and passing CI; prohibit force pushes to shared branches. Otherwise document the same review gate and enforce it as a team—do not claim the server enforces it. Add long-lived release branches only if you genuinely maintain multiple versions.
Branch from an up-to-date main
Check git status before switching. Finish or safely preserve unrelated local work first. Pull main with --ff-only, create a descriptive branch such as feature/42-booking-conflict, and commit only relevant files after reviewing the staged diff. Push the branch and open a draft PR early when the approach is risky.
Review behavior, not just formatting
Link the issue and acceptance criteria; explain what changed, why, how to test, risks and screenshots where useful. The reviewer checks logic, failure cases, tests, accessibility/security and documentation, then runs the change when practical. Label feedback as blocking or optional; criticize the code, not the person. The author fixes comments, adds evidence and requests re-review.
Resolve conflicts together
Agree who coordinates overlapping edits. If main changed, merge origin/main into your feature branch after fetching, resolve the intended behavior with the other author, then rerun tests and push. Never choose “ours/theirs” blindly or use reset --hard to make a conflict disappear. If the update is confusing, pause and ask for a paired review before changing shared history.
Merge, verify and release deliberately
After approvals and fresh passing checks, squash-merge if that is the team convention, delete the merged feature branch and verify the integrated acceptance criteria. Update the task’s status and evidence. Tag a tested milestone on main; not every commit is a release. Repair a bad merge through a reviewed revert/fix PR, and consider data compatibility before rolling back a deployment.
Example commands inside an already-cloned repo
Run one line at a time, only with a clean working tree. The example path must exist in your project; substitute your actual changed file, issue and branch. Stop and read any error. Review and merge happen in the PR after these commands.
git status
git switch main
git pull --ff-only
git switch -c feature/42-booking-conflict
# Implement and run the relevant tests, then:
git diff
git add src/booking.ts
git diff --staged
git commit -m "Prevent overlapping bookings (#42)"
git push -u origin feature/42-booking-conflict
Use calls to remove blockers and make decisions, not to read the task board aloud. Written updates keep absent teammates included and leave evidence for your report.
How to do it & worked example: Keep sync-ups short and decisions written
Send an asynchronous three-line update
On agreed workdays, post: finished since the last update + issue/PR link; next action; blocker + the help needed. Update the board first. Set a response window that respects classes and sleep. Raise blockers when discovered, not only at the next scheduled call.
Try a 15-minute sync when needed
Before: share the agenda and links. Minutes 0–3: check the milestone and blocked cards. Minutes 3–10: agree decisions or pair people to investigate. Minutes 10–15: confirm each action’s owner and due/check-in date. Move deep debugging to a smaller follow-up with only the needed people. Cancel the call if written updates solve everything.
Demo weekly, improve one habit
Spend 20–30 minutes showing the integrated slice against acceptance criteria, including a failure—not slides alone. Ask the supervisor for decisions at agreed reviews. Then spend 10 minutes on what helped, what hurt and one process change to try next week. Replan unfinished work using remaining capacity; do not quietly carry every task forward.
Leave a decision trail
Publish a short note: date, attendees, decisions and reasons, actions with owner/date, unresolved questions and links to issues or ADRs. Summarize for absent members; confirm disagreements instead of assuming silence is approval. Do not record calls without consent or place private participant information in public notes.
A sync-up outcome, not “discussed database”
Decision: keep server-side atomic conflict protection (ADR-01); client-only checks fail with concurrent requests. Action: issue #42 owner reproduces the race before Thursday’s review; a second teammate reviews the test. Blocker: sandbox database access; supervisor contact assigned. Fallback: reduce the equipment catalogue, not the integrity rule.
06 · At acceptance criteria, during coding and before release
Design tests around risk, not a coverage trophy
Write the test approach before implementation. Use fast focused checks for rules, integration tests for boundaries and a few end-to-end journeys for what users must be able to do.
How to do it & worked example: Design tests around risk, not a coverage trophy
Choose the highest-risk behaviors
List each requirement, what can fail and the impact. Prioritize lost/corrupted data, unauthorized access, incorrect results and unusable core journeys before cosmetic issues. For each test record ID, requirement, level, owner, setup, inputs, action and expected result. Mark not-run work honestly; a planned test is not evidence of passing.
Test rules and real boundaries
Unit tests isolate deterministic logic: empty input, boundaries and invalid states. Integration tests exercise real database constraints, migrations or service contracts in an isolated test environment. Mock external services where needed, but do not mock away the database behavior you are claiming to verify. Reset test data and control clocks/randomness where practical.
Verify the user journey and failures
Automate a small set of critical end-to-end journeys using user-visible behavior and stable accessible locators. Cover success, validation, permissions, empty/error states and recovery. Avoid arbitrary sleeps and shared test accounts that interfere with each other. Test the production build on the real deployment path as well as local development.
Add manual and specialist checks
For interfaces, check keyboard-only use, visible focus, labels, zoom, narrow screens and relevant languages/themes; automated accessibility scans cannot prove conformance. In an authorized sandbox, check role permissions, secret handling and invalid input. Set a realistic performance target with device, dataset and workload before measuring. Adapt evidence for ML, hardware and networks in the project-type section; web E2E is not a substitute for model evaluation or hardware safety.
Turn defects into regression evidence
A bug report needs environment/commit, minimal reproduction, expected versus actual behavior, impact and safe logs. Distinguish severity (harm) from priority (when to fix). Reproduce, add a failing regression test where practical, fix, rerun the affected tests and core journey, then ask a peer to verify. Investigate flaky tests; retries are diagnostic, not a reason to hide failures. Coverage helps find gaps but 100% does not prove correctness.
TEST-01: a plan for REQ-01, not fabricated results
Unit: touching time intervals do not overlap under the agreed rule; invalid/reversed intervals are rejected. Integration: with an empty isolated database and two valid users, submit competing reservations concurrently; assert exactly one success, one conflict and one stored booking.
End-to-end/manual: the unsuccessful user gets a clear, keyboard-reachable recovery path and can choose another slot. Security: a different user cannot cancel somebody else’s booking. Recovery: a cancelled slot becomes available again without duplicate records.
Run record: commit/tag, database and app versions, fixture, command, timestamp, expected/actual, pass/fail/blocked/not-run and log or screenshot. Repeat on the release candidate and link failures to issues. No invented pass counts, latency numbers or screenshots.
Continuous integration runs agreed checks whenever changes are proposed. Start small, keep the checks trustworthy and build the artifact that you actually test and hand over.
How to do it & worked example: Make checks repeatable and releases recoverable
Create a fast pull-request gate
On pull requests and main updates, use a clean runner, pinned runtime and locked dependency install. Run formatting checks (not silent auto-fixes), lint/static checks, unit and relevant integration tests, then a production build. Add schema/content checks for content sites. Use the same documented commands locally and in CI; a skipped check must not be described as passed.
Test the release candidate
Serve the built artifact in an isolated test environment and run critical E2E checks. Before a milestone tag, also run the broader regression suite, accessibility/manual checks, migration and recovery rehearsal, and a clean setup by someone else. Use safe fixtures and stub third-party services; student CI should not charge real cards, email real users or modify production data.
Keep logs safe and failures visible
Use minimal CI permissions and protected secrets only when necessary; do not expose them to untrusted pull-request code. Keep test reports and useful failure artifacts with sensible retention, removing personal data. Fix a failed gate before merging; document any explicitly approved exception, owner and follow-up instead of disabling the test to get green.
Practice a release and a handover
Name the tested commit/tag, artifact checksum when useful, config, migration steps, known limitations and release owner. Rehearse a smoke test and a safe rollback/restore; code rollback cannot undo an incompatible data migration. Give the next maintainer setup, architecture decisions, test commands, open issues and access-transfer instructions without secrets in the report. Keep an offline demo backup permitted by your rubric.
A pipeline students can explain
Pull request → clean install → format/lint/type checks → unit/integration tests → production build → preview smoke/E2E → peer review → merge. For a milestone, add full regression, manual checks and independent reproduction before tagging the verified commit.
For CSE-Pothik specifically: yarn install --immutable; yarn check; yarn build; yarn verify:build; then set PLAYWRIGHT_SERVER=preview with the same BASE_PATH and run yarn test:e2e and yarn test:a11y. These are this repository’s commands, not a universal pipeline for every stack.
Ten templates are included in one Markdown toolkit. Copy the sections you need into your task manager or repository. These are prompts to fill in, not completed evidence; nothing is saved or submitted here.
Project brief & risk register
Agree the smallest useful outcome with your supervisor before committing to scope.
Title / team / supervisor / review date / rubric link:
User and problem / real evidence or research question / permission to use evidence:
Smallest measurable outcome / in scope / explicitly out of scope:
Deadline / weekly capacity / budget / equipment and data constraints:
Risk / impact and likelihood / early warning / owner / mitigation or fallback / next review:
Ethics, privacy and safety approvals / approver / status / evidence link:
Team agreement & milestone plan
Write together at kickoff; revisit when availability or scope changes.
Members / weekly availability / absence and handoff arrangements:
Shared board and repo / communication channel / response window / escalation contact:
Issue owner and reviewer rule / rotating facilitation and release roles / contribution credit:
A smaller project with a real question and reliable evidence teaches more than a large feature list nobody can finish.
Start with your department rubric and supervisor’s constraints: dates, team size, ethics approval, assessment and required report format.
Name the user or research question, current problem, evidence that it exists and the smallest useful outcome. Seek consent before interviews; avoid collecting sensitive data by default.
Write in-scope and out-of-scope items, budget/tooling limits, top three risks and an alternative if data, lab access or a dependency fails.
Enough for now
A one-page brief that another person can explain back to you, with supervisor feedback recorded.
Not yet: Do not choose microservices, blockchain or an AI model before explaining the problem they solve.
‘Fast, secure and user-friendly’ cannot guide implementation until you say what observable behavior counts.
Give each critical requirement an ID, a user scenario and an observable acceptance criterion; include failure and recovery behavior.
Choose measurable constraints appropriate to your lab: response time with a stated dataset/device, supported screens, accessibility checks and data-retention limits.
Link requirements to design decisions, implementation and tests. Review the small traceability example below with a peer.
Enough for now
A prioritized requirement list and test matrix; someone can tell what passes, what fails and what is deliberately excluded.
Not yet: Do not invent performance targets or pretend a usability claim is validated without observation.
A diagram is useful when it explains boundaries and trade-offs, not when it contains many fashionable boxes.
Draw components, data flow, trust boundaries and deployment or experiment setup. Define API/data contracts and failure states where relevant.
Record one important decision: context, at least two options, chosen approach and consequences. Prefer a simple modular design unless evidence requires more.
Identify data owners, minimal permissions, secrets handling, dependency licenses and credible threats before implementation.
Enough for now
A peer can trace one scenario through the design and explain a rejected alternative and one unresolved risk.
Not yet: Do not add distributed services, Kubernetes or custom authentication just to look industrial.
A repeatable team workflow is part of the project, not paperwork added the night before submission.
Use version control from the start, a short issue list, clear commits and small pull requests. Record individual contributions without turning commit counts into a productivity score.
Make one end-to-end slice run early. Review requirements, code/design and tests together. Solo? Ask a peer or supervisor for a scheduled review.
Automate formatting, static checks and relevant tests in CI; pin dependencies, document tool versions and keep secrets and real personal data out of Git.
Enough for now
A fresh checkout runs using documented steps; a reviewed change shows its requirement, test result and contribution.
Not yet: Do not save integration until the final week or submit a tutorial clone without explaining your own contribution.
A successful demo shows one path. Engineering evidence also explains boundaries, failure modes and what remains unknown.
Test critical logic, component boundaries and an end-to-end journey. Include invalid input, permissions, data loss/recovery and a realistic device or dataset constraint.
For interfaces, test keyboard, focus, labels, contrast, resizing and error recovery; use automation plus manual checks. Record actual devices and assistive tools used, not assumed coverage.
Run relevant security/dependency checks and a bounded performance experiment only on authorized systems. Record environment, method, actual results and limitations; fix important defects and rerun affected tests.
Enough for now
A traceable test report with pass/fail results, fixed-defect evidence and explicit remaining risks—not a claim of zero bugs or universal security.
Not yet: Do not chase 100% coverage, hide failures, fabricate participants or use AI-generated measurements as results.
‘It works on my laptop’ is a starting observation, not a handover plan.
Tag a release; provide source, setup instructions, tool versions, example configuration without secrets and safe sample data. Respect licenses and access restrictions.
Have a peer rebuild or rerun the experiment from the instructions. Record failures and repair the instructions or setup before repeating.
For deployed systems, document logs, backup/restore, rollback and who maintains or shuts down the demo. For offline projects, provide a reproducible local run and explain deployment limits.
Enough for now
An independent reproduction note tied to the release and a tested recovery procedure where relevant.
Not yet: Do not pay for production hosting or expose sensitive data just to show a public link.
You should be able to explain why the work is useful, how you know, and what you would change next.
Follow the department report format. Cover problem, related work, method/design, implementation, evaluation, limitations, ethics and references; distinguish your work from borrowed assets and code.
Prepare a short demo with a normal path, a failure/recovery path and evidence linked to a requirement. Keep an offline backup demonstration for connectivity problems.
Disclose AI/tool use under your department policy, verify every citation and explain any generated code you retain. State each member’s contribution and unresolved issues.
Enough for now
A report, reproducible artifact and defense that agree with one another; a new maintainer can identify the next safe change.
Not yet: Do not call a student prototype production-ready, a paper accepted, or a design certified unless you have the relevant evidence.
This is a teaching example. Adapt it to your domain and supervisor’s expectations.
REQ-01 · Requirement
Two confirmed bookings must not overlap for the same equipment.
AC-01 · Acceptance
With two competing requests, exactly one succeeds; the other receives a clear conflict, with no duplicate reservation.
ADR-01 · Decision
Use atomic conflict protection at the server/data layer, not only a disabled button; verify the chosen database’s behavior with a test.
TEST-01 · Verification
An integration test sends concurrent requests for the same interval; also test adjacent times, cancellation and retries.
REL-01 · Handover
Link the release tag, environment, actual test log and known limits in the report. No fabricated screenshots or pass results.
Different projects need different evidence.
Go deeper into your own branch. You do not need to build every kind of project.
Web / mobile / software
Show a usable core journey, API/data contracts, permission boundaries, automated and manual tests, accessible failure states and release instructions. For mobile, test lifecycle, offline state and actual target devices where available.
A public deployment is optional; a repeatable local demonstration can protect privacy and control cost.
Research / data / machine learning
State a research question, source and permission for data, baseline, train/validation/test separation, leakage checks, metrics with uncertainty and reproducible environment/seeds. Report negative results and error analysis.
A high accuracy number is not a contribution by itself. Publication is a separate review process, not a graduation promise.
Hardware / embedded systems
Provide schematics, BOM, firmware/tool versions, test conditions, simulation versus measurement, calibration/uncertainty and supervised safety review before physical work.
Simulator-first. A student demonstration is not an electrically certified product; no unsupervised hazardous circuits.
Networks / security / infrastructure
Document an isolated topology, authorization, threat/failure model, versioned configuration, traffic/test plan, monitoring evidence and rollback. Remove credentials and sensitive packet payloads.
No campus, public or client-system experiments without explicit permission and a defined safe scope.
The pre-submission evidence audit
This is not a score or tracker. Show evidence for each claim in a team review. For gaps, reduce scope, fix the issue or document the limitation and discuss it with your supervisor.
The supervisor/rubric requirements and team contributions are documented.
Critical requirements have observable acceptance criteria and linked results.
The main design decision and rejected alternative are explained.
A peer can run the tagged artifact using the README and safe data.
Tests include a failure case; results name the environment and remaining limitations.
Relevant accessibility, privacy, security and physical-safety risks are reviewed.
Licenses, citations, dataset permissions and AI assistance are honestly attributed.
Recovery/handover steps and known issues match the demo and report.
One action this week
Use the template to write a one-page brief and one acceptance criterion. Ask a peer to explain it back in five minutes. Revise the unclear part—that is your first useful review.
This guide is original editorial synthesis, not an endorsement by the reference providers. External references are primarily in English. Each source has its own review date below.
Use linked issues, small tasks and shared project views. The board states and student timeboxes in this guide are editorial suggestions, not GitHub requirements.
Learn the branch, pull-request, feedback and merge cycle. Adapt review and branch-protection settings to the team and hosting plan; this is not the heavier Gitflow model.
Understand event-triggered workflows, runners, jobs and steps. Choose project-specific checks; merely using Actions does not make a project production-ready.
Use user-visible behavior, test isolation and resilient locators for web E2E tests. This source does not cover all unit, research or hardware testing needs.
Use the review principles for small, understandable changes and constructive feedback. These are engineering practices, not a university grading rubric.
Select relevant application-security checks with your supervisor and document scope. A student checklist does not establish ASVS compliance or certify security.