You're in Week 2 of Month 7. Submission is 8 weeks away. Your FYP is in a state.

The frontend loads but the API calls hang. The database schema is half-designed. You don't actually understand what your own code does anymore. Your supervisor said "looks good, keep going" two months ago and hasn't replied to emails since. And everyone else in your cohort seems fine.

You're not fine.

Here's the honest version: most FYPs are like this at this point. The difference between a B and a D isn't how much code you write in the next 8 weeks. It's what you fix right now.

The Three Most Common FYP Disasters

1. Scope Creep (You're Building Two Projects)

You started with a simple idea. By month 5, you've added features, integrated third-party APIs, redesigned the UI twice. Now you're juggling a real-time notification system, a recommendation engine, and three different databases.

Eight weeks left. You can't finish two projects.

What actually works: Cut 60% of what's not core to your project. Not the future features. Not the nice-to-haves. Cut them completely. A well-executed simple project beats a half-finished ambitious one. Every examiner knows this.

2. Wrong Stack Choice (You're Fighting Your Tools)

You chose Django because your friend recommended it. Or you learned React and committed to it even though your API is in Node and half your code is glue just to make them talk.

You're spending 40% of your time debugging environment issues and 20% refactoring because the architecture is fighting you.

What actually works: If it's salvageable (same language across frontend/backend, working CI/CD), fix the architecture. Add a proper API layer. Document what talks to what. If you chose the wrong stack entirely, you're past the point of changing. Accept it and move forward with what you have.

3. Supervisor Misalignment (They Want a Thesis, You Built a Product)

Your supervisor marked off on your proposal. Then they went silent for two months. Now feedback comes back saying your approach is "not academically rigorous enough" or the scope should be bigger or you should have done XYZ literature review.

Your code is weeks from complete. They want you to pivot.

What actually works: Schedule a meeting. Not email. Face-to-face or Zoom call. Clarify exactly what they need to sign off (technically and academically). Show them what you have. Most supervisors are reasonable when they see actual progress. What they hate is silence and assumptions.

What You Can Actually Fix in Eight Weeks

You can't rewrite the codebase. You can't learn a new stack. You can't change your project scope and expect quality.

What you can do:

Week 1-2: Stabilize Get the core flow working. If your frontend and backend don't talk cleanly, that's the priority. Spend these two weeks on the API contract — what data flows between frontend and backend, in what format, under what conditions.

Don't optimize. Don't add features. Just make the core path reliable.

Week 3-4: Fill Gaps Now that the core works, what's broken? Data validation missing? Error handling non-existent? Security holes? Database queries that time out?

Fix these systematically. One section at a time.

Week 5-6: Documentation & Reproducibility Can someone (your examiner) run your code? Without you standing over them telling them which environment variables to set?

Document setup. Document the code. Document design decisions.

Week 7-8: Buffer Don't code during these weeks. Test. Find the edge cases. Fix crashes. Write the report.

This is when most people panic-code and introduce new bugs. Don't.

When To Get Outside Help (And What to Look For)

If you reach week 3 and the core still doesn't work, your timeline just contracted. You need help.

Real FYP help means:

Someone who understands your stack (actually understands, not "I watched a tutorial once")
Someone who can debug with you, not just write code
Someone who explains what's broken and why, not just patching symptoms
Sessions focused on you understanding what you built

Not someone who:

Takes over and codes for you (you won't understand it for your defence)
Charges by the hour to hand-hold you through basics
Disappears after delivering code
Promises to "finish it for you"

Cheap "FYP completion" services exist. Don't use them. Universities are getting better at detecting bought code. And more importantly, you'll face your examiners in a defence where you have to explain every decision. If you can't explain your own project, you fail.

The Honest Talk

Your FYP doesn't have to be beautiful. It doesn't have to be production-grade. It doesn't have to be feature-complete.

It has to:

Work — core functionality runs without crashing
Be defensible — you understand every major decision
Be documented — someone can understand what you built from your report and code comments
Show scope awareness — you did something realistic in the time available

If you're two months out and none of these are true, it's crisis mode. But crisis mode has a path forward. And it doesn't involve all-nighters rewriting everything.

It involves ruthless prioritization, finding the right help, and focusing on understanding over perfection.

Your B+ is waiting. But only if you act now.