I'm a third-year software engineering student and need to complete, document, and test an independent project for my curriculum. It counts for about 40% of my final grade, so I want to choose something substantial rather than throw together a generic CRUD app with an AI feature.
I've already built several projects to learn different technologies, including a basic Vim-like text editor in C++ with custom commands. I also have experience with React, React Native, Flutter, and Python projects involving NLP and machine learning. One possibility is to continue developing the editor by adding features such as a file tree, built-in syntax highlighting, debugging support, or other capabilities that aren't available in the standard tool.
However, I'm unsure whether improving an existing concept is enough to justify a year-long final project. Does a project need to solve a completely new problem, or is building a better and more usable version of an existing tool acceptable? For people who have faced a similar decision, how did you narrow down your idea and decide whether it had enough scope for a final project?
4 Answers
Look for problems you repeatedly encounter in your own life or studies. Think of tasks where you’ve wished for a tool, or repetitive work that could be automated, then check whether the idea is useful to other people too. That approach usually produces a more focused project than trying to force together whatever technologies are currently popular. Your existing editor is worth considering because you already understand its limitations and can identify improvements from firsthand experience.
A year is plenty of time if you treat the project as an engineering study rather than just a feature list. Start with a narrow core objective, build a prototype, and leave room for testing with real users, performance measurements, documentation, and an evaluation against existing editors. You could also investigate a specialized area such as developer tooling, accessibility, or support for a particular workflow. Be cautious about adding AI or cybersecurity simply because they sound impressive; the project should be manageable, ethically safe, and something you can explain and implement yourself.
You may be overestimating how much novelty is expected. A final project usually needs to demonstrate that you can plan, build, document, and test a nontrivial system. It doesn’t necessarily need to become a groundbreaking product. Even a relatively ordinary application can be a good project if the requirements, architecture, testing strategy, and evaluation are well done. Given your existing experience, your editor could let you spend more time on engineering quality rather than rushing to learn an entirely unfamiliar stack.
Your code editor is already a much stronger starting point than a generic CRUD application. You don’t need to invent an entirely new category of software; you can define a specific problem and make your tool solve it better. Features such as a project file tree, syntax highlighting, integrated search, debugging workflows, version-control support, or improved accessibility could provide plenty of scope if you design, implement, test, and evaluate them properly. Just avoid adding features randomly—choose a target user and explain what makes your editor useful to them.
That makes sense. The editor is already functional, so my concern was whether adding features would be considered enough work for a full year. I’ll try to frame it around a specific user problem and measurable improvements instead of just collecting features.
I agree about avoiding AI for its own sake. It might be tempting to add an automated coding assistant, but a well-tested editor feature with a clear purpose would probably make a stronger academic project than an unexplained AI add-on.