What Makes an FYP Stand Out: Lessons from Real Projects
Looking across finished student projects, the ones that score well share a small number of habits. None of them are about building something bigger.
Strong final year projects share four habits: they solve one clearly defined problem, they isolate a single genuinely hard component, they evaluate against a baseline with an honest limitations section, and they are written up so a reader who was not present can follow the reasoning. Projects score badly when they attempt broad feature lists with no measurable claim.
It is worth looking at finished projects rather than idea lists, because the differences between a strong submission and a weak one are visible immediately. They are not about ambition, budget, or how many months were spent.
Across the projects published in the MyUni showcase, covering domains from attendance tracking to crop disease detection, the same patterns keep appearing.
Pattern one: one problem, stated plainly
Take the difference between these two framings of a similar project.
Weak: A platform that uses AI to improve campus life through attendance, events, and engagement.
Strong: A system that marks attendance from a single lecture hall camera, reducing the five minutes per class currently spent on a roll call.
The second is narrower and sounds less impressive. It is also completable, testable, and easy to defend. The first will produce a demo with three half finished modules and no evaluation.
Every strong project description names an actual user. A lecturer with a fifty seat class. A student revising for one specific course. A small clinic with no electronic records. If the user is everyone, the evaluation is impossible.
Pattern two: one hard component, done properly
Strong projects have exactly one piece that is genuinely difficult, and they go deep on it. Everything else is deliberately boring. Login, forms, and lists are not the project.
In the showcase, the projects that read as most complete are built this way. A paper recommendation engine spends its effort on the ranking approach. An attendance system spends it on the recognition pipeline. A proctoring tool spends it on the real time detection constraint. The surrounding application exists to make the hard part usable, not to be the hard part.
Why this helps you at assessment
When you have one deep component, your report has a natural centre. You can write several pages on the design decisions, the alternatives you rejected, and the measurements you took. Projects spread across many shallow components have nothing to say about any of them.
Pattern three: a number, and a baseline
This is the clearest dividing line. Strong projects report a metric against a comparison. Weak projects report only that the system works.
| Project type | A defensible result |
|---|---|
| Recognition system | False accept and false reject rates on a held out set |
| Recommender | Precision at k, compared with a popularity baseline |
| Real time detection | Frames per second and latency on named hardware |
| Management system | Task completion time against the current manual process |
| Classifier | Accuracy alongside a majority class baseline |
The baseline does not need to be sophisticated. A popularity ranking or a majority class predictor is completely acceptable and often more convincing than a weak competing model, because it is honest about what counts as improvement.
Ninety eight percent accuracy looks strong until the reader learns that ninety eight percent of the data belongs to one class. Always report the class balance and the baseline next to your headline metric.
Pattern four: an honest limitations section
Weak projects end with a list of future features. Strong projects end with a clear account of what the system cannot do.
A limitations section shows that you understand your own work. It reads like this: the model was trained on images captured in one building, so performance in different lighting is untested. The recommendation engine has no cold start strategy. The proctoring system logs more data than a privacy review would likely allow.
Each sentence names a real boundary. Examiners respond to this because it demonstrates judgement, which is harder to teach than technical skill and harder to fake.
The write up is where most marks are won
Students consistently underinvest in writing. The report carries a large share of the marks, and a well argued report about a modest system beats a thin report about an ambitious one almost every time.
Write during the project, not after it. Keep a decision log from week one: what you tried, what happened, what you changed. By the time you write the report, that log becomes your methodology chapter with almost no additional work. Without it, you will be reconstructing decisions from memory two months later and the detail will be gone.
A showcase entry that states the problem, what you built, the measured result, and what you would change is useful to the next batch of students and to anyone reviewing your work. The MyUni showcase is built for exactly this and accepts finished projects from any university.
None of these four patterns requires a bigger project. They require a narrower one, a baseline, and a willingness to write down what did not work. That combination is what separates a submission that scores well from one that merely exists.
Frequently asked questions
What separates a good FYP from an average one?+
A clear problem, a named hard component, and an honest evaluation with a baseline. Average projects demonstrate features. Strong projects prove a claim with a number and then explain where that claim stops being true. The differences are usually visible in the results chapter before anyone reads the code.
Should I publish my FYP on a showcase or portfolio?+
Yes, if you write it for a reader who was not in the room. State the problem, what you built, what you measured, and what you would change. Recruiters and supervisors both read these, and a clear write up of a modest project is more persuasive than an unclear description of an impressive one.
Is it better to do a complex project badly or a simple project well?+
A simple project done well, every time. Examining is about rigour. A narrow system with a proper evaluation and an honest limitations section demonstrates more ability than an ambitious system that half works and was never tested. Complexity is not the goal and graders do not reward it.
How much of my FYP should be code versus writing?+
Plan for roughly equal time on each, even though it feels wrong while you are building. The report carries most of your marks, and a well argued report about a smaller system consistently outscores a thin report about a larger one. Start writing in the middle of the project rather than at the end.
Start your project on MyUni
Browse notes from Operating Systems, Machine Learning, Computer Vision and more, or publish your own work to the project showcase so the next batch can learn from it.