Theory
Choosing your tools
Now you decide what to build it with: your technology stack, the front end, back end, database, and cloud. By this point in your degree you know many options, web frameworks, mobile toolkits, several databases, Python, so the challenge is not learning them but choosing wisely among them.
The key principle: choose by fit, not fashion. The 'best' stack is the one that suits your problem, your timeline, and your team's skills, not the trendiest one. This lesson guides that choice, so you build on a foundation that helps you finish rather than one that fights you all semester.
At a glance
| Layer | What it is | Examples you know |
|---|---|---|
| Front end | The user interface (web or mobile) | Angular, React (web); Kotlin, Flutter (mobile) |
| Back end | The server-side logic and APIs | Node/Express, PHP, .NET, Python |
| Database | Where data is stored | MySQL (relational); MongoDB, Firebase (NoSQL) |
| Cloud / hosting | Where it runs and is served | Firebase Hosting, and other hosting platforms |
Theory
Choose by fit, not fashion
Four things should drive your choice.
The problem's needs: is it a web app, a mobile app, or both? Is it data-heavy (favouring a strong database) or real-time (favouring something like Firebase)? Let the problem point you.
The time available: a final-year project is short. Do not try to learn an entirely new stack under deadline; use what you can be productive in now.
Your team's existing skills: build on what you already know well. If your team is strong in React and Firebase, that is likely your stack.
Resources and cost: prefer free tiers and tools you can access. Fit the stack to your reality, and it becomes an ally, not an obstacle.
Quiz
Your team is strong in React and Firebase, and the project is a web app due in one semester. A friend suggests learning a brand-new framework nobody knows because it is trendy. What is the wise choice?
- Learn the new trendy framework, because newer is always better
- Use React and Firebase, the stack your team already knows well and can be productive in now, since it fits the problem and timeline
- Use as many different technologies as possible to impress
- Pick technologies at random
Show the answer
Use React and Firebase, the stack your team already knows well and can be productive in now, since it fits the problem and timeline
The wise choice is to use React and Firebase, the stack the team already knows well and can be productive in immediately, since it fits a web app on a tight timeline. Option A is a trap: newer is not always better, and learning a whole new framework under deadline wastes precious time on a learning curve instead of building, risking an unfinished project. Option C (cramming in many technologies) adds complexity and integration problems for no benefit, hurting a time-limited project. Option D is obviously unwise. Choose by fit, not fashion: the best stack for a student project is usually the one your team is already productive in and that suits the problem and timeline.
Think first
Why does a familiar 'boring' stack often beat an exciting new one for a project?
New technologies are exciting. Why is choosing the stack you already know usually the smarter move for your project? Then tap.
Show the answer
Because for a time-limited project, the goal is to SHIP a working system, and a stack you already know lets you spend your limited time BUILDING rather than LEARNING and DEBUGGING unfamiliar tools, so the 'boring' familiar choice reliably gets you to a finished product while the exciting new one often does not. When you use technology you know well, you are productive from day one: you know how to structure the code, you recognise and fix errors quickly, you know the pitfalls, and you can focus your energy on solving your actual problem and building your features. When you pick a brand-new stack under deadline, a large chunk of your scarce time goes to LEARNING it, reading docs, watching tutorials, making beginner mistakes, and getting stuck on problems that an experienced user would breeze past, all before you have built anything of value. Worse, unfamiliar tools spring surprises: undocumented quirks, integration headaches, and bugs you cannot diagnose because you do not yet understand the system, and under a deadline those surprises can be fatal to finishing. The excitement of a new framework is real, but excitement does not ship software; steady, confident progress does. This does not mean never learn new things, learning is valuable, and you can explore new tech in low-stakes settings or note it as future scope. But your final-year PROJECT, which is assessed on a finished, working result under a fixed deadline, is usually the wrong place to gamble on unfamiliar tools. The professionals' saying 'choose boring technology' captures this: reliable, well-understood tools that you and your team can wield fluently are what let you deliver, whereas chasing the newest thing often means fighting your tools instead of building your product. So for the project, favour what you know: it maximises the time you spend creating value and minimises the risk of not finishing. Familiar and productive beats exciting and unfinished.
Summary
Key takeaways
- Your technology stack is the set of tools you build with: front end, back end, database, and cloud/hosting.
- By final year you know many options; the skill is choosing wisely, by fit, not fashion.
- Let the problem's needs guide you (web or mobile? data-heavy or real-time?).
- Respect the short timeline: do not learn a whole new stack under deadline; use what you can be productive in now.
- Build on your team's existing skills and prefer accessible, free tools.
- A familiar stack lets you spend time building, not learning and debugging, so it usually beats an exciting new one for a project.
- Memory hook: pick the stack that fits your problem, timeline, and skills, familiar and productive beats trendy and unfinished.