How to Complete Your FYP in 2 Weeks (When You're Running Out of Time)

Look, we're not here to judge. Life happens. Assignments pile up. You lost motivation. Your original FYP direction didn't work out. And now your submission is 2 weeks away and you need to figure out what's actually possible.

We've helped a lot of students in exactly this situation. Some came to us with 10 days left. Some with less. The outcome depends on what you're willing to do in those two weeks — but it's almost never hopeless.

This guide is practical and honest. No motivational fluff, no generic "just work harder" advice.

First: Be Brutally Honest About Where You Are

Before you can plan the next 2 weeks, you need to know exactly what you have and what you don't. Write this down right now:

What you have:

Any working hardware or code (even partial)
Completed report sections (proposal, literature review, methodology)
Data collected, results documented
Components already on hand

What you're missing:

Working prototype or software
Test results / data
Report sections (chapters 3, 4, 5 are usually the ones not done)
Documentation

Once you can see the full list, stop feeling overwhelmed by the whole thing and start prioritising ruthlessly.

The 2-Week Survival Plan

Days 1–2: Lock the Scope Down Hard

This is not the time to add features. This is the time to cut everything that isn't essential to proving your project works.

Ask yourself: what is the absolute minimum version of this project that demonstrates the concept and can produce results I can write about?

For an IoT project, that might mean: basic sensor reading → sends data to a simple dashboard → shows a graph. Not the fancy mobile app, not the machine learning layer you imagined, not the multi-user login system.

For a software project: core function works, basic UI, can demo it.

Write that minimum scope down. That is your target. Everything else is a "nice to have" that gets cut.

Talk to your supervisor in these two days. Even if you've been avoiding them. A short honest message explaining where you are is far better than disappearing until submission. Most supervisors would rather know now than find out at the viva. Many will help you rescope the project to something achievable.

Days 3–8: Build Only What's in Your Scope

With a locked scope, six days of focused work is more than enough to produce a working prototype for most FYP projects. But "focused" means cutting out everything else.

A realistic daily target:

| Day | Target | |-----|--------| | 3 | Hardware setup / code environment set up, basic proof of concept working | | 4 | Core functionality working end-to-end, even if messy | | 5 | Fix the 2–3 critical bugs blocking the demo | | 6 | Connect all parts together (sensors + logic + output/display/dashboard) | | 7 | Run tests, collect 5–10 data points you can put in the report | | 8 | Photograph everything, record a video of it working |

Day 8 is critical. By the end of Day 8, your project should be "done" in the sense that it works and you can demo it. What you have left is documentation.

Days 9–12: Write the Report (It's Not As Hard As You Think)

Most students waste days staring at a blank page. Here's the structure that gets the job done:

Chapter 1 — Introduction (1–2 hours) Problem statement, objectives, scope, expected outcomes. You probably wrote a version of this in your FYP 1 proposal. Adapt it.

Chapter 2 — Literature Review (4–6 hours) You need 10–15 references minimum. Use Google Scholar. Find papers related to your technology and project topic. You don't need to read the whole paper — read the abstract, introduction, and conclusion. Write 3–5 sentences about each in your own words and cite it. One afternoon's work.

Chapter 3 — Methodology (3–4 hours) How did you build it? Block diagrams, flowcharts, circuit diagrams, system architecture. If your project is built, this is mostly drawing what already exists. Use draw.io for quick diagrams.

Chapter 4 — Results and Analysis (4–6 hours) This is where the data you collected on Day 7 goes. Tables of readings, graphs showing system performance, accuracy comparisons, response time measurements. Every result needs a sentence of analysis. "The average response time was 1.2 seconds, which meets the requirement of under 2 seconds."

Chapter 5 — Conclusion (1–2 hours) Summarise what you did, whether you met your objectives, and list 2–3 future work ideas. This is the easiest chapter. Do it last.

References and Appendices Use Mendeley or Zotero to format references automatically. Paste in your code as an appendix. Add your circuit diagram as an appendix. These bulk up the report without taking much time.

Days 13–14: Viva Preparation

By Day 13, your report should be submitted or nearly done. These final two days are for the viva.

Prepare a 5-minute explanation of your project:

What problem does it solve?
How does it work (technically)?
What were your results?
What would you improve?

Practice saying it out loud until it feels natural. In your bedroom, to a friend, to anyone who'll listen.

Prepare your demo:

Test the demo 5 times in a row without failure before the viva
Have a backup video on your phone
Bring a power bank
Bring a second USB cable

The most common viva disaster is technical failure during the demo. Don't let that happen.

Expect these questions:

"Why did you choose this technology?"
"How accurate is your system?"
"What are the limitations?"
"What would you improve if you had more time?"
"Explain how this part of your code works."

You know your project. Trust that.

What If the Hardware Isn't Working?

This happens. Sometimes a sensor is faulty, a module doesn't behave as documented, or a bug takes days to find. If you're on Day 8 and something still isn't working, you have two choices:

Option A: Swap to a simpler version Can you demonstrate the concept with something simpler? A software simulation of the hardware behaviour? A partial system that still proves the idea works? Examiners value understanding over completeness.

Option B: Get professional help There's no shame in it. At Rectronx Circuits, we regularly help students who are stuck — not by doing the project for them, but by troubleshooting what's broken and explaining what's wrong. A 30-minute call can sometimes save days of debugging. WhatsApp us and describe what's happening. We'll tell you what it is.

The Things That Actually Matter for Passing

After helping students through hundreds of vivas, here's what actually determines whether you pass:

1. The project has to work. Even if it's basic, it needs to do something demonstrably. Examiners can tell the difference between "works" and "works in this one specific situation" — and they'll forgive the latter if you're honest about it.

2. You understand what you built. You don't need to have built every line from scratch. But you need to be able to explain what every part does. If you can't answer "what does this sensor read?" or "why did you use this algorithm?", that's a problem.

3. The report tells a coherent story. Introduction sets up the problem. Methodology explains your approach. Results show what happened. Conclusion wraps it up. If the examiner can follow that thread, you're in good shape.

4. You don't panic. Examiners expect nervousness. They do not expect you to fall apart. Know your project, know your results, and be honest about limitations. "This didn't work as expected because X, and given more time I would Y" is a great answer.

A Note on Getting Help

At Rectronx Circuits in Penang, we work with students at every stage of FYP — including the "I have 10 days left" stage. We're not going to lecture you about time management. What we will do is help you figure out what's still achievable, fix what's broken, and make sure you can stand in front of your examiner with confidence.

WhatsApp us at +60 11-7279 2500. Tell us where you are and what you're building. We'll give you an honest assessment and a plan. No commitment required.