To make a final year project demo video, record the project working end to end, including one test you cannot repeat live in the exam room, and wrap it in a short drawn explanation of the problem, the architecture and your results. Keep it to three to six minutes unless your department sets a length, and order it the same way as your report: problem, objectives, design, implementation, testing, results, limitations. That way every scene points to a chapter, and every chapter sets up a viva question you have already rehearsed. The video is your insurance if the live demo fails, and your evidence for anything that took days to measure.

Why a recorded demo, when you will demo live anyway

In most Indian engineering colleges, the final year (major) project in a B.E. or B.Tech is assessed through a series of internal reviews with your guide and a panel, then a final demonstration and viva voce in front of an external examiner, often in the eighth semester. Many colleges also run a project expo where visitors walk past your stall. In UK universities, the individual or group project in a BSc, BEng or MEng is usually assessed through a dissertation or report plus a demonstration, presentation or poster session, and some departments add a viva. Your module handbook or university project guidelines are the final word on what is required.

In both systems, the live demo is where things break. The college Wi-Fi blocks your MQTT port. The sensor that worked for three months gives nonsense in a crowded hall. The laptop with the trained model refuses to project. Examiners have seen all of it, and most are sympathetic for about a minute.

A recorded demo video does four jobs a live demo cannot:

Ask your guide or supervisor whether a recorded video can be shown in the final demo, and whether it can be submitted with the report. Most say yes to playing it as support. A few panels want to see everything run live, and then the video is still useful as rehearsal and as the expo loop.

The structure, mapped to your report

The examiner has read your report, or at least the abstract and results. A video in the same order feels familiar, and it makes the viva easier because their questions follow the same path.

The literature survey section is the one most videos skip. Keep it to one scene: two or three existing approaches drawn side by side, and the one thing none of them does that yours does. It is often the first thing an external examiner asks about.

Worked example: IoT smart irrigation

Smart irrigation is one of the most common final year projects in Indian electronics and computer science departments, which is exactly why a clear demo video makes one stand out. Here is a scene list for a project where soil moisture sensors on an ESP32 decide when to switch a pump, and skip watering if rain is forecast. The numbers are illustrative; yours must come from your own tests.

1. The problem. A farmer's field drawn from above, half of it waterlogged, half of it dry. "Small farmers near our college irrigate on a fixed timetable. In our survey of twelve farmers, ten watered on schedule even after rain."
2. The objectives. A card with three targets that will come back later: reduce water used by 25% against a fixed schedule; keep soil moisture between 30% and 60%; switch the pump within ten seconds of a decision.
3. Existing work. Three boxes: timer-based controllers, sensor-only systems, and commercial systems. One line under each. "None of the low-cost systems we found used the weather forecast, so they water just before rain."
4. Architecture. Built up one box at a time as each sentence is spoken: capacitive soil moisture sensor, ESP32, MQTT broker on a Raspberry Pi, a decision service that checks a weather forecast API, a relay and pump, a web dashboard.
5. The live run, recorded. Screen and phone footage side by side. The sensor is pushed into dry soil, the dashboard shows 22%, the pump relay clicks on within four seconds. Water is added, the reading climbs past 55%, the pump switches off.
6. The test you cannot repeat. A drawn timeline of a fourteen day trial on two plots, one on the old timetable and one on the system, with rain days marked. On both rain days, the system skipped watering, while the timetable plot was watered anyway.
7. Results. The objectives card returns with measured values beside each: water saved 21% (target 25%, missed, one sentence on why); moisture in range 91% of the time; pump response 4 seconds.
8. Limitations and future scope. "We tested on two plots in one season. Next, we would add a solar supply and test on a full field."

Notice scene 7. The missed target is shown, with a reason. In a viva, an examiner who finds a missed target you did not mention will spend ten minutes on it. One you raise yourself takes thirty seconds.

Recording the demo without it looking staged

• Record the main path in one take. Cuts in the middle of a demo make examiners wonder what was cut. If it takes two minutes, let it take two minutes and speed it up in the editor, saying so on screen ("shown at 4x").
• Show the screen and the hardware together when both matter. A phone on a stand filming the board, plus a screen recording of the dashboard, placed side by side.
• Make the text readable. Increase the browser zoom or terminal font before recording. Examiners will watch on a projector at the back of a lab.
• Include a failure case. Unplug the sensor and show the system raising an alert. Robustness is what separates a project from a tutorial you followed.
• Keep the raw files. If asked, you can show the unedited recording and the logs from the same day.

Make it

1. 1

   List your report chapters

   Write one line per chapter: problem, objectives, literature, design, implementation, testing, results, future scope. That list is your scene order.

2. 2

   Record the live run and the long test

   One unbroken take of the main path, plus footage or logs from the test that took days. Note the date of each recording.

3. 3

   Write the explanation script

   About 120 to 150 words a minute of video for the non-demo sections. Put the objectives as numbers, and say plainly which target you missed.

4. 4

   Draft the drawn scenes

   Paste the script into openCanviz, choose Keep my wording so the narration matches your report, and pick whiteboard for the architecture. Generate the voice, or record your own if your guide prefers it.

5. 5

   Check every label against your block diagram

   Pause on each scene and compare the components, arrows and numbers with your report. Drafted diagrams can add a box you never built. Fix it in the editor before exporting.

6. 6

   Rehearse the viva with the video

   Play each section to a friend and have them ask the question in the table above. If you cannot answer one, fix the report or the video before the panel does.

Common questions

How long should a final year project demo video be? Follow your department if it gives a length. If not, three to six minutes for the viva or submission, and a 60 to 90 second loop for the expo stall, made as a separate short script rather than a trim of the long one.

Should my face be in it? Not necessary. Examiners care about the project working and your understanding, which they will test in person anyway. A title card with your names, roll numbers or student IDs, and your guide's name is enough.

Is it allowed to use a generated voice or AI drawings? Check your college or university policy and ask your guide. The design, the code and the results must be your own work. Drafting narration and drawings from a script you wrote is closer to formatting, but declare any tool you used if asked, and never let a drafted diagram show something you did not build.

Our project is a group project. Who speaks? One clear voice for the video is easier to follow. Put each member's role on screen in the closing scene, and expect the viva to test each person separately on their own part.

How is this different from a capstone or hackathon video? A capstone showcase video, described in how to make a video explaining your capstone engineering project, is written for judges, sponsors and recruiters. A hackathon video, in how to make a hackathon demo video in an hour, proves a weekend build works. This one is written for an examiner who has your report open, which is why it follows your chapters. If your code itself is being assessed, how to make a video explaining your code for a class submission covers the walkthrough.