The presentation is where the project is defended, not explained. The panel has your report; the viva exists to check that you built what it describes and understand it. The deck is a supporting act — its job is to keep you on track and give the examiners something to look at while you talk. Aim for 12 to 18 slides, one idea each, for a 10 to 15 minute slot.
One rule sits above the structure: the deck, the diagrams and the demo must all describe the same system. A slide showing a feature your demo cannot perform is the fastest way to turn a friendly viva hostile. Everything below assumes the deck matches the code on your laptop.
1. Title and problem
- Title slide — project name, your name, guide, college, roll number
- The problem, stated concretely — who has it and why it matters
Do not spend three slides warming up. One clean title slide, then one slide that names the real problem. If the examiner understands the problem by the end of slide two, the rest of the talk has a spine.
2. Objectives, existing vs proposed
- Objectives — the numbered list straight from your synopsis
- Existing systems and what each does badly
- Your proposed system, side by side against them
A simple two-column “existing versus proposed” slide does a lot of work: it justifies the project’s existence in one glance and sets up every result you will claim later. Keep the objectives to the same wording you used in the report so nothing contradicts.
3. Architecture and design diagrams
- Architecture diagram — the components and what flows between them
- ER diagram matching your actual database
- Data flow diagram, level 0 and level 1
Show one diagram per slide and explain it — trace the flow with your cursor rather than reading labels. These slides are where examiners test whether you designed the system or downloaded it, so be ready to defend why a table is separate or why a flow is asynchronous.
4. Tech stack and modules
- The technologies used, with a one-line reason for each choice
- The modules the system breaks into
- Which modules are core and which are supporting
“We used MongoDB because the data is document-shaped and the schema evolved during the build” is an answer. “We used MongoDB because it is popular” is not. Every tool on this slide is an invitation for a question, so have a reason ready for each.
5. Screenshots and live demo
- Screenshots of every core screen, in the deck as a fallback
- A short live demo of the main flow, if the setup allows it
- Seeded, realistic data — never “asdf” and “test”
This is the part the panel came to see. Rehearse the exact click path until it is automatic, and seed the database with realistic data beforehand so the screens look like a real product. Keep screenshots in the deck too: if the laptop, network or projector fails, you present the flow from those and lose nothing.
6. Testing and results
- How you tested — unit, integration, user acceptance
- A small test-case table: input, expected, actual, pass or fail
- What the system achieves against each objective from slide two
Include a test that catches bad input, not only tests that pass. A results slide that maps back to the objectives you opened with closes the loop and makes the whole talk feel finished rather than merely stopped.
7. Limitations, future scope, conclusion
- Limitations — stated honestly, before the panel finds them
- Future scope — three or four concrete extensions
- Conclusion — one line on what was built and learned
Every system has limits, and a slide that owns them reads as maturity, not weakness. Make the future scope specific — “add SMS alerts using the existing notification module” beats “the system can be enhanced further”. Then close in one line and stop; a talk that ends cleanly leaves a better impression than one that trails off.
Handling the questions
- Know your own code. The surest questions are about the part of the system you understand least. Read your own report and be able to explain any diagram in it.
- If you do not know, say so. “I did not implement that; here is how I would” is a strong answer. Bluffing is the one thing an experienced panel always catches.
- Answer the question asked. Do not launch into a rehearsed speech. Listen, answer in a sentence or two, and stop.
- Lean on your scope. “Why does it not do X” is fully answered by the out-of-scope boundary you declared in the synopsis.
- Stay calm on a hostile question. A hard question is a chance to show you understand the system, not an accusation. Treat it as one.
Every project on this site ships with the deck, the report, the diagrams and the synopsis already written to match the code — and each one is walked through with you in live sessions so the demo and the answers are yours, not memorised. See the projects, and prepare with the viva questions panels actually ask and the report format that the deck should match. Need one built and rehearsed end to end? Start with a custom build.