FYP Demo Day Survival Guide for Singapore Students

The final year project is graded twice: once on what you built, and once on the twenty minutes where you demo it and answer for it. Plenty of good projects lose marks not because the work was weak but because the student fell apart in the room. The demo and viva are a different skill from the build, and they are very coachable.

What examiners actually grade in the demo

Three things, mostly:

1. Does it work, live, right now. A project that runs on your laptop but stalls in front of the panel reads as fragile, fairly or not.
2. Do you understand what you built. Examiners probe for the boundary between what you genuinely grasp and what you assembled and hoped about.
3. Can you justify your decisions. Why this database, this framework, this approach over the obvious alternative. "It was in the tutorial" is not an answer at this level.

Scope matters too, but in a specific way: examiners reward a smaller thing done well and understood over an ambitious thing that half-works and that you cannot fully explain.

The failures that sink good projects

• The live demo crashes. Networks fail, data is not seeded, a last-minute change broke something. Always have a recorded run of the working system as a fallback, and demo on the actual machine and setup you will use on the day, rehearsed end to end.
• Over-claiming. Saying your system "uses machine learning" when it calls one library function invites exactly the question you cannot answer. Claim only what you can defend.
• Freezing on "why". The questions are predictable. If you have not rehearsed answering why you made your three or four biggest decisions, you will stumble on the easy ones.

Defending AI-assisted work in 2026

Here is the part that has changed. Your examiners assume you used AI. Using it is not the problem; not understanding what it produced is. The violation, at most institutions now, is undisclosed or ununderstood use, not use itself.

So the standard you are held to is simple: you are accountable for every line, regardless of who or what wrote it. If a panel points at a function and asks what it does and why it is there, "the AI generated that" is the one answer that will hurt you. Walk through it as if you wrote it, because as far as the grade is concerned, you did. Before the demo, go through your own codebase and make sure there is nothing in it you cannot explain. If there is, either understand it or take it out.

The prep routine that works

In the final week: rehearse the full demo at least twice on the real setup, write down the three hardest questions a sceptical examiner could ask and prepare honest answers, and prepare a clean response to "what would you do differently", because it is almost always asked and a thoughtful answer signals maturity rather than weakness.

Where I help

FYP consultation is the work I most enjoy, and the demo and viva are where a bit of outside pressure-testing pays off most. I will sit as the difficult examiner, ask the questions your supervisor is too polite to ask, and find the soft spots in your defence before the panel does. If that would help, message me on Telegram.