Final Year Project Rescued 2 Months Before Submission

The Problem

Darren was 8 weeks from submitting his final year project. He had a React frontend and a Flask backend — built from tutorials and Stack Overflow — and he couldn't reliably explain how either worked.

This matters because FYPs aren't just about submitting code. They're about defending it. His panel would ask why he made specific architecture choices. He didn't have answers because he hadn't made choices — he'd copied patterns he didn't understand and hoped they'd hold together.

The code itself had problems: React state was being mismanaged in ways that caused silent bugs, Flask routes were inconsistent, and the API contract between frontend and backend had never been properly designed.

What We Worked Through

We went through the entire codebase together, file by file. The goal wasn't just to fix it — it was to make sure Darren understood every decision so he could defend it under examination conditions.

React state management — Identified where state lived inappropriately, where prop drilling was creating unnecessary complexity, and where a simple refactor would make the logic obvious. Darren rewrote the affected components himself, with guidance. By the end, he could explain precisely why state was structured the way it was.

Flask API design — The routes were functional but not coherent. We restructured them around REST conventions, standardised error responses, and added basic input validation. More importantly: Darren could now explain what a REST API is and why his design decisions made sense.

Architecture decisions — Why React over plain JS for this use case. Why Flask. How the frontend and backend communicate. What the data model represents. These aren't hard questions if you understand your own project — but they're impossible to answer if you don't.

Systematic debugging — Walked through how to isolate a bug, what information to gather before Googling, how to read error messages properly. This is a skill most students never get explicitly taught.

Submission prep — Report structure, how to write about technical decisions for a non-technical examiner, what the panel is actually looking for.

Outcome

• Submitted on time
• Awarded B+ grade
• Could answer every question the panel asked about architecture, technology choices, and implementation
• Left with a much clearer mental model of full-stack development

Quote

"My FYP was in a bad state two months before submission. We worked through it and I actually understood what I'd built by the end. Got a B+." — Darren, Year 4 CS, NTU