Identity 2026 / Department instructions
BCA
Build a real client website, fix a daily frustration, and prove software can recover from failure.
Authoritative Identity 2026 rules
Before you begin
- Work begins on 12 October 2026. This replaces the 13 October start in the Fashion briefs.
- Enter individually or as a team of two maximum. This also applies to third-year Graphic Design.
- The final submission deadline is 27 October 2026 at 5:00 PM IST (India time).
- Submitted projects appear in the public gallery. Fashion’s restriction on publishing before results is waived for Identity 2026.
These event rules supersede conflicting wording in the original briefs. Where a 15-day roadmap is supplied, Day 1 is 12 October and Day 15 is 26 October. The final submission deadline remains 27 October at 5:00 PM IST.
Department-wide guidance
BCA Design & Innovation Hackathon 2026
- AI Use Declaration.
MP4, 1080p, landscape, English voice-over or captions.
Every team member must be heard or seen.
Each screen must stay on screen for at least 4 seconds and be readable.
Upload to the college website by the deadline.
First Semester
Ajmer Goes Online
1st Semester
Brief: Ajmer Goes Online
Your first real client. Your first real website. Built only with HTML and CSS.
The challenge
Ajmer is full of small businesses that customers cannot find online — the tailor, the sweet shop, the bookshop, the tiffin service, the craftsperson, the coaching centre. When someone searches for them on Google, they find nothing or a blurry map pin.
Find one real business or person in Ajmer that has no website, meet them, understand what their customers need to know, and build them a complete website using only HTML and CSS.
Who can be your client
- Any small shop, artisan, home business, service provider or NGO in Ajmer that does not have its own website. An Instagram page or Google listing alone is fine — they still qualify.
- A family business is allowed, provided you follow the same process.
- Not allowed: chains, franchises, or businesses that already have a website.
- You must take the client’s permission in writing (a signed note or a WhatsApp message is enough) and include it in your submission.
What you must build
- At least 4 pages: Home, About (their story), Products/Services/Menu, and Contact. A fifth page (Gallery or Customer Reviews) is optional.
- Semantic HTML5 structure: header, nav, main, section, footer; one h1 per page; headings in the correct order.
- One external CSS file for the whole site. A consistent colour palette and type style drawn from the client’s identity — apply the visual principles you have learned in class.
- Responsive layout: the site must work on a mobile screen (360 px wide) and a laptop (1280 px wide), using Flexbox and/or Grid and at least two media queries.
- Real content only: your own photographs (taken with permission), real prices, timings and address. No “lorem ipsum”, no stock photos of products the client does not sell.
- Useful features that need no JavaScript: click-to-call link, WhatsApp chat link, email link, and an embedded Google Map of the location.
- Accessibility basics: alt text on every image, readable colour contrast, meaningful link text, and the lang attribute set.
- Optimised images: compress every image (aim for under 300 KB each) so the site loads fast on mobile data.
Not allowed
- JavaScript of any kind.
- Website builders (Wix, WordPress, Canva Sites, Google Sites).
- Downloaded HTML/CSS templates or CSS frameworks such as Bootstrap or Tailwind — we want to see your own CSS.
Quality checks (show screenshots in your process sheet)
- W3C HTML Validator (validator.w3.org): aim for zero errors.
- Lighthouse report in Chrome DevTools: aim for an Accessibility score of 90 or above.
Bonus (up to 5 extra marks)
- Publish the site live for free on GitHub Pages or Netlify and hand the link to your client.
- A Hindi version of key pages, linked from the English site.
- A print-friendly menu or price list using a print media query.
What to submit
- Video (5–7 minutes) uploaded on the college website — structure below.
- Source code as a zipped folder, or a GitHub link.
- Process sheet (1–2 pages, PDF): client details; 5 questions you asked and their answers; sitemap; photo of your hand-drawn wireframe; your colour and font choices with reasons; validator and Lighthouse screenshots.
- Client permission note.
Video structure
| Time | What to show |
|---|---|
| 0:00–0:45 | Meet the client — who they are and what problem not being online causes them |
| 0:45–1:30 | What they told you they need |
| 1:30–2:30 | Your plan: sitemap and wireframe |
| 2:30–4:30 | Walk through the website on laptop and on mobile (use DevTools device mode) |
| 4:30–5:30 | One piece of your code you are proud of — explain it |
| 5:30–6:30 | A 20–30 second reaction from your client, and what you learned |
AI Use Declaration
Every entry must include this table. List every AI tool you used. Honest, detailed declarations are respected; hidden use is not.
| AI tool | What I asked it to do | What I wrote, changed or checked myself |
|---|---|---|
| e.g. ChatGPT | Explain how CSS Grid areas work | Wrote my own grid layout for the menu page and tested it on mobile |
| — | — | — |
| — | — | — |
Declaration: I/We confirm that this entry is our own work, that every AI tool used is listed above, and that I/we can explain every part of the submitted code.
Name(s): ____________________ Signature(s): ____________________ Date: __________
Video Rules
File name: BCA1_TeamName_City.mp4
Second Year
One Frustration, Fixed
2nd Year
Brief: One Frustration, Fixed
Find a daily frustration. Build the fix. Java is the brain, JavaScript is the face.
The challenge
Pick one frustration that real people around you face every day, and build a working web application that fixes it. The logic — rules, calculations, data — must be written in Java. The interface people click and type into must be built with JavaScript. The two must talk to each other.
Choose one problem statement
| Code | Problem | Who suffers |
|---|---|---|
| A | Canteen Rush — a pre-order and token system so students do not lose their break standing in the canteen queue | Students, canteen staff |
| B | Roommate Split — a shared-expense tracker for hostel and PG roommates: who paid, who owes, settle up | Students living away from home |
| C | Medicine Minder — a medicine schedule and stock reminder that a family manages together for elderly parents | Families, older people |
| D | Notes Exchange — peer-to-peer lending of books and notes among students, with due dates and a waitlist | Students |
| E | Your own problem — must be approved by your mentor by Day 3 | — |
What you must build
Java — the brain (back end)
- At least 4 meaningful classes showing encapsulation, and inheritance or interfaces where they make sense.
- Collections (ArrayList, HashMap, etc.) and exception handling for wrong or missing input.
- Data that survives a restart — stored in a file or a database (SQLite, MySQL or similar).
- Your logic exposed as a REST API (Spring Boot, Javalin, or Java’s built-in HttpServer) with at least 4 endpoints covering create, read, update and delete.
- At least 5 unit tests written in JUnit.
JavaScript — the face (front end)
- A responsive interface in HTML, CSS and JavaScript.
- DOM manipulation, event handling and form validation in the browser.
- fetch() with async/await calling your Java API, with clear loading and error messages for the user.
- At least one smart feature: search or filter, sorting, a live counter, a chart, or a reminder/notification.
Engineering habits
- A GitHub repository with a README: the problem, how to run the project, screenshots, and the list of API endpoints.
- Commits on at least 6 different days across the 15 days — we want to see your work grow, not appear on the last night.
- No passwords or secret keys written inside the code.
- Frameworks (React, Vue, Bootstrap, Tailwind, Spring Boot) are allowed, but in your video you must explain what the framework is doing for you.
Real-user test (compulsory)
At least 3 real people from your chosen user group must use your application. Record what they said, and show one change you made because of their feedback.
Bonus (up to 5 extra marks)
- Login with properly hashed passwords.
- Live deployment (for example, the Java API on Render or Railway and the front end on Netlify).
- The application packaged with Docker.
What to submit
- Video (6–8 minutes) uploaded on the college website — structure below.
- GitHub repository link with README.
- One-page architecture diagram: Browser → JavaScript → API → Java → Database.
- User test notes (who tested, what they said, what you changed).
Video structure
| Time | What to show |
|---|---|
| 0:00–0:45 | The frustration — show it for real (the queue, the confusion, the argument) |
| 0:45–1:45 | Who suffers and what they told you |
| 1:45–2:45 | Your architecture — how JavaScript and Java talk to each other |
| 2:45–5:15 | Live demo of a complete user journey, including what happens when someone enters wrong data |
| 5:15–6:15 | Code walk-through: one Java class, one JavaScript function, and your tests running |
| 6:15–7:30 | User feedback, what you changed, and what you would build next |
AI Use Declaration
Every entry must include this table. List every AI tool you used. Honest, detailed declarations are respected; hidden use is not.
| AI tool | What I asked it to do | What I wrote, changed or checked myself |
|---|---|---|
| e.g. ChatGPT | Explain how CSS Grid areas work | Wrote my own grid layout for the menu page and tested it on mobile |
| — | — | — |
| — | — | — |
Declaration: I/We confirm that this entry is our own work, that every AI tool used is listed above, and that I/we can explain every part of the submitted code.
Name(s): ____________________ Signature(s): ____________________ Date: __________
Video Rules
File name: BCA2_TeamName_City.mp4
Third Year
Self-Healing Software
3rd Year
Brief: Self-Healing Software
Build software that notices it is failing, fixes itself, and keeps serving people — then prove it on camera.
The context
All software fails. Servers crash, internet drops, an outside service stops responding, bad data slips in, and on results day ten times the usual number of people arrive at once. The world’s leading technology companies design systems that detect these problems and recover on their own — often before any user notices. Netflix famously built a tool called Chaos Monkey that deliberately switches off its own servers, simply to prove the system survives. This field is called Site Reliability Engineering, and it is one of the most valued skills in the software industry.
The challenge
Build a working application for a real, high-stakes situation. Then make it self-healing: it must detect at least four different kinds of failure by itself, work out what went wrong, and recover automatically — with no human restarting anything. Finally, break it deliberately on camera and prove that it heals.
Choose one scenario
| Code | Scenario | What will go wrong |
|---|---|---|
| A | Results Day Portal — a university result portal | Traffic jumps tenfold at 10 am; the database slows down |
| B | Campus Pay — fee or canteen payment flow (use a simulated payment gateway, never real money) | The gateway times out or fails mid-payment |
| C | Clinic Queue — OPD token and appointment system for a small clinic | Internet drops at the reception desk |
| D | Order Tracker — quick-commerce delivery tracking | The outside location service is slow or returns bad data |
| E | Your own scenario — must be approved by your mentor by Day 3 | — |
The self-healing toolkit — implement at least 4
At least one of your mechanisms must heal a crash (1 or 8) and at least one must heal a failing outside service or connection (2, 3, 4 or 5).
| # | Mechanism | What failure it heals |
|---|---|---|
| 1 | Health checks and automatic restart (watchdog, PM2, Docker restart policy) | The app crashes or freezes |
| 2 | Retry with exponential backoff | A brief network or service glitch |
| 3 | Circuit breaker (e.g. Resilience4j) | A failing outside service — stop calling it, fail fast, test again later |
| 4 | Fallback and graceful degradation | Show cached or last-known data instead of an error page |
| 5 | Offline-first with later sync (service worker, local queue) | Internet drops — save actions, send them when back online |
| 6 | Self-repairing data | Corrupt or invalid records — detect, set aside, repair from backup or rules |
| 7 | Rate limiting, queueing or load shedding | A sudden traffic spike |
| 8 | Automatic rollback | A bad new version fails its health check and is rolled back to the last good one |
| 9 | Resource self-management | Memory or disk running out — detect and clean up |
| 10 | AI-assisted diagnosis (advanced) | An AI model reads the logs and suggests or applies a known fix, with a human-approval safeguard |
What you must build
- A working core application for your scenario — it must be genuinely useful before any healing is added.
- A health dashboard (a web page) showing the live status of each part of your system in green, amber or red, with an incident log and a count of recoveries.
- Structured logging: every incident recorded as Detected → Diagnosed → Action taken → Recovered, with timestamps.
- A chaos script or “chaos button” that injects each failure on demand — stop a process, block a service, corrupt a record, flood the app with requests. Judges will use this to verify your claims.
- Measurements: for every failure, record time to detect and time to recover. Aim for recovery within 30 seconds with no human action. Show the difference between your app without healing and with healing.
The honesty clause
Show at least one failure your system cannot heal yet, and explain why. Good engineers earn trust by knowing the limits of what they have built.
What to submit
- Video (8–10 minutes) uploaded on the college website — structure below.
- GitHub repository with README and the chaos script.
- Resilience Report (3–5 pages, PDF): architecture diagram; a failure table (failure, how it is detected, how it heals, measured recovery time); before-and-after numbers; known limits.
Video structure
| Time | What to show |
|---|---|
| 0:00–1:00 | The stakes — who gets hurt when this app fails |
| 1:00–2:30 | Architecture, and why you chose these healing mechanisms |
| 2:30–3:30 | The app working normally |
| 3:30–7:30 | Chaos demo: inject each failure live — dashboard turns red, then heals to green, with a timer on screen |
| 7:30–8:30 | Your numbers: recovery-time table, before versus after |
| 8:30–9:30 | What it cannot heal yet, and what you would build next |
Annexure: AI Use Declaration
Every entry must include this table. List every AI tool you used. Honest, detailed declarations are respected; hidden use is not.
| AI tool | What I asked it to do | What I wrote, changed or checked myself |
|---|---|---|
| e.g. ChatGPT | Explain how CSS Grid areas work | Wrote my own grid layout for the menu page and tested it on mobile |
| — | — | — |
| — | — | — |
Declaration: I/We confirm that this entry is our own work, that every AI tool used is listed above, and that I/we can explain every part of the submitted code.
Name(s): ____________________ Signature(s): ____________________ Date: __________
Video Rules
File name: BCA3_TeamName_City.mp4
Ready to submit?
Create your Identity 2026 project, invite your teammate if applicable, and share your project and video links before 27 October 2026, 5:00 PM IST. The existing project form accepts a project link and a YouTube demo link. Keep every supporting deliverable listed above and contact your department coordinator for any additional file-submission instructions.
Create your project →Questions about your brief, approvals, or assessment? Contact your department coordinator.