A useful live project gives a real person a task they can complete, then gives you evidence that the task works. For a CSE student, that can be a small application used by a consenting campus group. It does not require a commercial client, an artificial intelligence feature, or access to someone's private records.
The ten ideas below are project briefs, not descriptions of products already built. Their users, sample inputs and acceptance checks are illustrative. Choose a problem you can investigate, deliver a small usable version, and describe your own contribution accurately. A deployed link alone does not establish reliability or real adoption.
What counts as a live project?
Use three separate descriptions in your portfolio. A prototype demonstrates a proposed workflow. A deployed demo runs at a shareable address, often with synthetic data. A pilot has consenting users who actually try the workflow. Call a project a pilot only when that happened, and record its scope and limitations.
Start by asking a possible user to show you the current process. Record the task, the person allowed to perform it, the failure that matters, and the evidence you will use to check success. Get permission before collecting data or using an organisation's name. An invented test account is enough for most early demonstrations.
Keep preparing
Continue with Sarkari Resume Templates₹299 — coaching के एक महीने से काफ़ी सस्ता / far cheaper than a month of coaching1. Campus equipment booking
User and task: A club coordinator lends a small set of tripods and microphones. Students need to see availability and request a time slot; the coordinator approves the request.
Smallest useful version: Equipment list, booking request, approval screen, cancellation and a record of who made each change. Keep maintenance blocks separate from student reservations. Decide whether a pending request holds the slot, and show that policy to users.
Acceptance check: Two approved bookings must not overlap for the same item. For example, under a declared half-open interval policy, 10:00–11:00 and 11:00–12:00 can coexist; 10:30–11:30 conflicts with the first booking. Test simultaneous requests as well as sequential clicks. A check performed only in the browser can miss a competing request.
Evidence to retain: The stated interval policy, conflict tests, an approval demonstration and an example of a cancellation making a slot available. Do not publish a list of students who borrowed equipment.
2. Accessible event information board
User and task: An event organiser publishes venue, time, accessibility information and later corrections. Visitors need the latest information without opening a social-media account.
Smallest useful version: Public event page, authorised editor, visible update time and a cancellation state. Use plain text for information that would otherwise exist only inside a poster. Keep optional access requests out of the public page.
Acceptance check: A visitor using only a keyboard can reach each interactive control, identify its purpose and complete the main task. A cancelled event must show its cancelled status on both the listing and detail page. Check the actual workflow with assistive technology where available; passing one automated scan does not establish full accessibility.
Evidence to retain: A recorded keyboard walkthrough, the cancellation check and a list of accessibility issues still open. Describe the particular checks you ran rather than claiming universal accessibility.
3. Study-room waiting list
User and task: A library desk manages a waiting list for a room. A student joins, sees their own position and leaves when no longer interested.
Smallest useful version: Join, leave, staff admission and an explicit queue policy. Make the public display anonymous. State what happens to an absent student and whether they can rejoin.
Acceptance check: Repeated submission by the same permitted identity must not create two active entries. If three entries have positions one, two and three, admitting the first leaves the other two in their original relative order. Test a staff action arriving at the same time as a student leaves.
Evidence to retain: State-transition tests and a demonstration using synthetic participants. A queue position is not a promise of an exact waiting time.
4. Repair-request tracker
User and task: A campus facility team receives reports of broken fixtures and assigns work. Reporters need to know whether their request was received and what its current status means.
Smallest useful version: Location, issue category, description, request reference and staff status changes. Keep submitted, assigned, resolved and closed distinct if the team needs that distinction. Limit who can see the report and its attachments.
Acceptance check: A reporter cannot edit another person's request by changing an identifier in the URL. Reopening a resolved request should follow the documented permission rule. Test this at the server, not just by hiding a button.
Evidence to retain: Permission tests, one complete synthetic request and the status definitions. An uploaded photograph may identify people or places; demonstrate with a staged image you have permission to use.
5. Small-store stock ledger
User and task: A consenting campus shop records stock received and issued. The operator needs to explain how the current quantity was reached.
Smallest useful version: Item catalogue and dated movement records. Treat corrections as explicit adjustments with a reason rather than silently rewriting history. Agree on a rule for negative stock and concurrent issues.
Acceptance check: Starting at 12 units, receiving five and issuing four gives 13. An adjustment of minus two gives 11. Verify the ledger and displayed total agree after each operation. If negative stock is forbidden, an issue of 12 from 11 must be rejected without partially changing the ledger.
Evidence to retain: The worked calculation, transaction tests and a correction example. This is an inventory exercise; do not present it as tax, accounting or payment-compliance software.
6. Assignment submission receipt service
User and task: A student submits a file and needs a clear receipt. A tutor needs to distinguish accepted submissions from failed uploads.
Smallest useful version: Submission window, allowed file types and size, upload result, receipt reference and authorised retrieval. Define whether resubmission replaces an earlier file or creates a new version. Keep submissions private.
Acceptance check: An interrupted upload must not produce a successful receipt. An accepted upload must be retrievable by an authorised user and match the original file. A content hash can help check integrity; it does not prove authorship or originality.
Evidence to retain: One successful and one interrupted-upload test, the version policy and permission checks. Use a demonstration document, not classmates' coursework.
7. Volunteer shift coordinator
User and task: An organiser fills event shifts while volunteers see and manage their own assignments.
Smallest useful version: Shift capacities, sign-up, cancellation, organiser approval if required, and a private roster. Show the time zone and location. Document whether a volunteer can hold overlapping shifts.
Acceptance check: A capacity-two shift cannot end with three confirmed assignments after simultaneous sign-ups. Cancellation restores capacity once. If overlap is prohibited, two conflicting assignments for the same volunteer must be rejected even when submitted from different tabs.
Evidence to retain: Capacity and overlap tests, plus a synthetic roster. Do not expose phone numbers or contact details in a public demo.
8. Course resource catalogue
User and task: A student group maintains links to authorised course resources. Readers need to distinguish current links from withdrawn or broken ones.
Smallest useful version: Subject, resource title, source link, contributor, review status and search. Link to material the group is permitted to share. A catalogue does not require copying or hosting the underlying document.
Acceptance check: A withdrawn resource disappears from normal search while an authorised editor can see its history. Test search on known titles and an empty query. A link returning HTTP 200 does not by itself establish that its content is relevant, safe or legally shareable.
Evidence to retain: A reviewed synthetic catalogue, search checks and the withdrawal workflow. Explain who reviewed a resource and what that review covered.
9. Public-service notice change monitor
User and task: A student wants to notice changes on a permitted public notice page and then read the official source.
Smallest useful version: A small allowlist of sources, restrained scheduled fetching, saved versions and a change log linking to the source. Respect source access restrictions. Mark failed fetches as unknown rather than interpreting them as deleted notices.
Acceptance check: An unchanged test page creates no new change entry. A changed fixture creates one entry with its fetch time. A timeout creates a fetch-failure record and leaves the previous successful version intact. Build these checks with local fixtures before contacting any live site.
Evidence to retain: Fixture tests and the fetch policy. A detected page change is not verification of eligibility, a deadline or an official decision; the source notice still needs to be read.
10. Personal study-session log
User and task: A learner records planned sessions, completed work and questions to revisit. They need an honest history rather than an automatically inflated streak.
Smallest useful version: Session plan, actual duration, topic, completion status and export. Give the user a way to correct an entry. Decide how sessions crossing midnight appear.
Acceptance check: A 23:50–00:10 session lasts 20 minutes under the stated local time and date assumptions. Editing a duration updates totals once. An incomplete session should not be counted as completed merely because its planned end time passed.
Evidence to retain: Date-boundary tests, corrected-entry totals and an export using invented entries. Logged minutes describe activity recorded; they do not establish learning or exam readiness.
Deliver a project you can defend
Choose one brief and write its acceptance checks before adding features. Build the main workflow, test failure paths, then invite a small pilot only when access and data handling are ready. Record what users actually did, what failed and what you changed. Keep a demo usable even if the pilot ends.
Your README should explain setup, data assumptions, the main workflow, tests, known limitations and your contribution. Remove secrets from both current files and repository history before sharing; changing a leaked credential is a separate necessary action. Prefer synthetic examples in screenshots and recordings.
A precise portfolio statement might read: “Built a deployed equipment-booking demo with synthetic accounts; implemented approval and overlap checks; tested adjacent and competing reservations.” Add real pilot numbers only after measuring them with permission. Do not turn a classroom exercise into a claim of a production client or guaranteed employment.
Frequently asked questions
Does every live project need AI?
No. Select features from the user's task. A simpler workflow with clear permissions and tested failure handling can provide useful engineering evidence.
Can a team project go on my resume?
Yes, with a clear account of your own work and the team's work. Keep review history, design notes and test evidence so you can explain the distinction.
What if I cannot find pilot users?
Build and label a deployed demo with synthetic data. Describe the proposed users and the checks completed. Do not invent adoption or a client relationship.
Further reading
GitHub's README documentation explains how a README communicates a project's purpose and how to get started. The ten briefs and acceptance examples above are original proposals; GitHub's documentation does not certify their implementation or predict their hiring value.
Related guides
Use the competency-assessment exercise to review a bounded task, then read the IT fresher resume guide when describing your own contribution.