The Moment of Panic

Mid-semester. FYP is due in 12 weeks. You've been "working on it." But your code? You don't really understand it. You're behind. Your supervisor seems disappointed. You're thinking about quitting.

Welcome to FYP hell. This is normal. Everyone's been here.

Unfiltered advice to get you out.

Why Most FYPs Fail (And It's Not Intelligence)

You're smart enough. You made one of these mistakes:

Mistake 1: Scope Creep

You proposed something ambitious. Your supervisor said "interesting" (code for: "that's a lot, but sure").

Now you're 8 weeks in with nothing working. You're building the next Facebook instead of validating one core idea.

Mistake 2: Not Understanding Your Own Code

You copied from Stack Overflow. You used ChatGPT to write functions. You don't actually understand why it works.

Now viva is coming. Your supervisor will ask: "Explain this function." You can't. You're sunk.

Mistake 3: Documentation Last

"I'll write the report when I'm done building."

End arrives. You've forgotten what you did in week 3. Writing feels impossible. Report quality tanks. You lose 20% of marks.

Mistake 4: Avoiding Your Supervisor

You're embarrassed about lack of progress. So you skip meetings. Hope the problem fixes itself.

Supervisor thinks you're fine. You're not. They find out at the last minute. Everyone's unhappy.

The Survival Framework (If You're Already Behind)

You can't undo past mistakes. But you can fix this.

Step 1: Stop Building. Start Scoping.

Right now. Today.

Ask yourself: What is the MINIMUM viable deliverable?

What's your core contribution? (Not: "I built a full e-commerce site." But: "I implemented real-time inventory tracking using WebSockets.")
What can you cut without losing your core idea?
What features look impressive but don't matter?

Talk to your supervisor about reducing scope. They'd rather you deliver something working than nothing ambitious. Everyone will be happier.

Step 2: Get Help (It's Not Cheating)

Asking for help understanding concepts: Allowed.

Getting code review: Allowed.

Having someone explain what your code does: Allowed.

Having someone write your code for you: Not allowed. Academic misconduct.

The line: You must be able to explain every line in your viva.

If there's code in your project and you can't explain it, remove it or learn it. Now.

Step 3: Document Starting Now

Don't wait for the report.

Every architecture decision: write it down
Every bug you fixed: write it down
Screenshots of working features: take them
Why you chose technology X over Y: note it

Your report will write itself. Because your notes ARE your report.

How to Talk to Your Supervisor (Damage Control)

Don't hide. Don't make excuses.

Be honest: "I'm behind. Here's where I am. Here's my realistic plan to finish. Can we reduce scope to X?"

Show you have a plan, even if progress is behind.

Supervisors respect honesty. They've seen FYP delays. What they hate is surprises at the last minute.

Email them today if you're behind. Don't wait.

Understanding Your Own Code (Crash Course)

If you copied code you don't understand:

Go through it line by line. What does each section do?
Add comments. Explain what each function does.
If you can't explain it, you shouldn't use it. Delete it or learn it.
Use ChatGPT to EXPLAIN code, not write it. Prompt: "Explain this function like I'm a beginner. What does each line do?"
Rebuild small parts from scratch. So you actually understand.

Don't just memorize your code. Understand it. Viva will expose shallow understanding instantly.

The Report (Where Marks Actually Come From)

Your code is 50-60% of FYP marks. Your report is 40-50%. Many students ignore the report. Mistake.

Structure That Works

Introduction: What problem are you solving? Why does it matter?
Literature Review: What already exists? Why isn't it enough?
Methodology: How did you approach this?
Implementation: What did you build? (With diagrams, screenshots)
Results: Does it work? How did you test it? What are the metrics?
Discussion: What are the limitations? What would you do differently?
Conclusion: Summary + future work

What Supervisors Actually Look For

Clear explanation of what you built
Evidence of critical thinking (not just "I did this")
Honest discussion of limitations
Proper references and citations
Writing that makes sense

Report Hacks

Start with methodology (easiest section)
Screenshots > walls of text
Diagrams explain architecture better than paragraphs
Write the abstract last (so it summarizes what you actually wrote, not what you planned)
Aim for clarity over complexity

The Viva (Oral Exam)

They will ask: "Explain how this works."

They will ask: "Why did you choose this approach?"

They will ask: "What would you do differently?"

They will ask: "What are the limitations?"

Prepare for these questions for every major component.

Practice explaining your project in 5 minutes. Out loud. To someone. You'll be asked this.

Emergency Timeline (If You Have 12 Weeks)

Week	Focus	Reality Check
1-2	Finalize scope. Reduce if needed. Talk to supervisor.	If you don't do this, weeks 3-12 will be chaos.
3-6	Core implementation only. No nice-to-haves.	Stop adding features. Focus on core.
7-8	Testing, bug fixes, cleanup.	Things don't work. Fix them.
9-10	First draft of report. Screenshots. Diagrams.	Report is 40% of marks. Treat it seriously.
11	Report revision. Viva prep.	Get someone to proofread. Practice explaining.
12	Final submission. Final viva.	Submit early if you can.

If you have less time, compress proportionally. But don't skip the report.

When to Get External Help

Tutoring for concepts you don't understand: Totally fine.

Code review from someone experienced: Fine.

Someone debugging with you: Fine.

The test: Can you sit in your viva and explain everything? If not, you have a problem.

CTA

Struggling with your FYP? Not sure where to start? We help university students debug, understand what they're building, and prepare for viva.

Not to do the work for you. To help you do it yourself. 1-to-1 so we can focus on your specific blockers.

Get help →