Picking a Tech Stack for Your FYP, Without Regret

Failed FYPs usually aren't failures of effort. They're failures of stack choice in week two that compound for the next nine months. By the time the team realises they should have picked Postgres instead of Firebase, they're too far in to refactor and too deep in deadlines to think clearly.

When students message me asking what to build their project in, the framework below is what I run through with them.

Pick boring technology

The single best advice for any FYP is to pick boring technology. Boring means well documented, widely used, easy to hire StackOverflow for, and unlikely to throw weird bugs you can't Google.

Boring stacks for SG FYPs:

• Web app: React + Node/Express + PostgreSQL, or Next.js full-stack
• Mobile app: React Native or Flutter (pick whichever the team already knows)
• Data project: Python + pandas + scikit-learn, or PyTorch if you must
• API service: FastAPI or Express, with Postgres

Not-boring stacks I see students pick that backfire:

• Kubernetes for a 3-user app
• A microservices architecture for a CRUD form
• Rust for the backend "for performance"
• A self-built ORM
• Anything blockchain (unless your FYP is literally about blockchain)

You'll not get bonus marks for technical novelty. You'll lose marks for missing features because you spent week six fighting your custom tooling.

Match the stack to the team's existing skills

If three of you know Python and one knows JavaScript, the backend should be Python. If everyone last touched Java in CS2030S, that's the language. If nobody has ever written a real backend, pick the framework with the best beginner docs (FastAPI, Flask, Spring Boot have great ones).

Trying to learn a new language during an FYP is a recipe for week-twelve panic. Build your project in something you already know, and use the FYP to learn how to architect something properly. That's the actually-useful skill.

Frontend choice, the simple version

For a web FYP frontend in 2026, you basically have three reasonable choices:

1. React + Vite (or Next.js): best ecosystem, biggest hiring market, well documented. Pick this if you ever want to use it at work.
2. Vue or Svelte: cleaner syntax, smaller cognitive load. Pick this if your team is small and the learning curve matters.
3. Plain HTML + a sprinkle of htmx or Alpine.js: surprisingly viable for content-heavy projects. Pick this if you don't need much interactivity and want to ship fast.

What you should not do: write the frontend in raw JavaScript with no framework. You'll spend six weeks rebuilding what React gives you for free, and your code will be worse.

Backend, even simpler

Pick the language your team is best at. Then pick the most popular framework for that language:

• Python: FastAPI (or Flask if you want even simpler, or Django if you need a CMS)
• JavaScript / TypeScript: Express (or Next.js API routes if you went Next.js)
• Java: Spring Boot
• Go: standard library, plus chi or gin

For 90% of FYPs, any of the above is fine. The framework choice doesn't matter as much as students think. The database choice matters more.

Database, the choice that haunts people

This is where I see the most regret. Two rules:

1. Use Postgres unless you have a specific reason not to. It is free, well documented, ACID compliant, and works with every framework. If you find yourself thinking "should we use MongoDB", the answer is almost always Postgres.
2. Don't use Firebase for anything that needs SQL-style queries. Firestore is fine for chat apps and simple CRUD. The moment you need a JOIN or an aggregation, you regret it.

When Firebase is genuinely a good choice: real-time multi-user collaborative apps, simple notifications, mobile-first prototypes. When it is a bad choice: anything resembling a relational data model. I've rewritten three FYPs out of Firebase mid-semester. You don't want to be the fourth.

Hosting and deployment

In 2026, your free options for a small FYP:

• Frontend: Vercel (Next.js especially), Netlify, or Cloudflare Pages
• Backend: Render, Railway, Fly.io free tiers, or Cloudflare Workers if it fits
• Database: Supabase or Neon free tiers (both Postgres)
• Storage: Supabase Storage, Cloudflare R2, or AWS S3 (free tier)

Avoid hosting on your own server unless your FYP topic is about hosting. The marker doesn't care whether your demo runs on Vercel or AWS, they care whether the demo runs.

Things to decide in week one

If your FYP starts next week, decide these in your first meeting:

1. The one-paragraph problem statement. What problem, for whom, what is the smallest possible thing that solves it.
2. The five core features for the first demo. Not 20. Five. Cut everything else into a "nice to have" list.
3. The stack (use the rules above).
4. The repo and branch strategy. A monorepo on GitHub, main branch protected, feature branches via PRs. Don't skip this.
5. The weekly meeting cadence. Same time every week, 30 minutes, write down decisions.

If you can't answer point 1 in plain English in one paragraph, your FYP isn't ready to start. Spend another week refining it.

Things to NOT decide in week one

• Microservices vs monolith. Monolith. Always.
• Whether to use TypeScript. Yes. Just yes.
• The CSS framework. Tailwind or whatever your frontend folks already know.
• The CI/CD pipeline. Just deploy on push. Anything fancier is procrastination disguised as engineering.

The check at week six

By week six of a 24-week FYP, you should have:

• A working core feature that you can demo to a stranger
• A repo with at least 50 commits across the team
• A deployed staging environment that anyone can access
• A clear list of which features are still missing

If you don't have those, don't push forward, fix the basics. The FYPs that ship great demos are the ones where the core was working in month two and the rest of the time was polish. The FYPs that fail are the ones where everything was "almost done" until week 22.

A second opinion before you commit

If you're at the stack-choice phase, drop me a line on Telegram with the project description. Ten minutes of conversation usually saves weeks of later regret.

Mid-FYP and the architecture has already gone wrong, message me sooner rather than later. The earlier in the project, the cheaper the fix. By week 18 the options narrow fast.

Week 22 and everything is broken, well, message anyway. I've seen it before. It can usually be salvaged, but the next two weeks will be intense.