Build Something Real: A Letter to FYP Students
Every semester I see the same list. To-do app. Tic-tac-toe. Weather dashboard. Library management system. Projects that were already tired ten years ago, built again this year, submitted, graded, and forgotten by everyone including the person who made them.
And lately the list has a new twist. The code is not even typed anymore. It comes from GPT in one giant paste, it runs on the second or third try, and the student moves on. Ask them how it is built, and the answer gets quiet. What problem does it solve? Which part was hard? Where did you get stuck, and how did you get out? Silence. The project exists, but the learning never happened.
Here is the part that worries me. Those same habits walk straight into the Final Year Project. The one project that is supposed to represent everything you learned in four years becomes one more recycled idea with borrowed code, and then it sits on a CV where an interviewer will take it apart in four questions. I have watched it happen. It is painful every time.
The problem is not AI. The problem is ownership.
Let me be clear about something, because students often expect me to say the opposite: I am not against AI coding tools. I use them daily. Code agents are the biggest shift in how software gets built since version control, and my favourite of them all is Claude Code. It writes with me, debugs with me, and ships with me. Pretending these tools do not exist is not discipline, it is denial.
But there is a difference between how a junior copies and how a senior builds, and it has nothing to do with typing speed.
A junior asks AI for the code. A senior asks AI for the code and stays responsible for every line of it.
A senior developer starts from the problem, not the prompt. They understand what they are building and why, they can explain every decision in the system, and when something breaks at 2 a.m. they know where to look. The agent multiplies their output because there is understanding underneath it. Multiply zero understanding by the best agent in the world and you still get zero.
And a senior never stops at "it runs on my laptop." The work is not done until it is ready for the user: deployed, tested against real inputs, usable by someone who has never seen your code and never will. That last mile is where all the real learning lives, and it is exactly the mile most students skip.
How to choose an FYP that changes your career
So here is what I tell every student who asks me about their Final Year Project. Do these two things in order.
First, decide your field before you decide your project. Where do you want to work after graduation? Machine learning, web platforms, mobile, security, data engineering, whatever it is, name it honestly. Your FYP is six to twelve months of focused work. Spent inside your target field, it becomes your first year of experience before you graduate. Spent on a random recycled idea, it becomes nothing.
Second, find a real problem inside that field. Not a project title from an old list. A problem that a real person or a real organization actually has. Visit a clinic, a shop, a farm, a university office. Look at what your own community struggles with. Real problems are everywhere once you start looking at the world instead of at other people's project lists.
When you solve a real problem in your chosen field, everything compounds. You are forced to learn the technologies that the industry actually uses, because toy stacks fall over when reality touches them. You experience real constraints: messy data, confused users, changing requirements. That is industry experience, and you collected it while still being a student. Walk into an interview with that story, where you can explain the problem, the decisions, the failures, and the fix, and you are no longer competing with the to-do app crowd at all.
Your FYP is not a course requirement. It is the first project of your career, wearing a university's paperwork.
Bring me your raw idea
I will end with an open offer, and I mean it literally. If you are a student staring at your FYP, or at any project, and you do not know whether your idea is real enough, bring it to me. It does not need to be polished. Raw is better. Half-formed is fine. "I noticed this thing is broken and I think software could fix it" is the best opening sentence there is.
I am available anytime for this. Click contact, drop your raw idea, and we will figure out together whether it holds a real problem and what it would take to build it properly.
Drop your raw idea →The tools have never been this powerful and the excuses have never been this weak. Ideas are cheap until shipped. Pick a real one, own every line, and ship it for someone who needs it. That is the whole secret, and it is available to every student willing to stop recycling.
