5 Projects Every Developer Must Build (2026 Edition)

5 Projects Every Developer Must Build (2026 Edition)

Last updated April 2026 — refreshed for current tools, frameworks, and real-world hiring expectations.

Building toy apps is easy. Building the right projects — the ones that teach you how production software actually works and that make a hiring manager stop scrolling — is harder. This guide covers five foundational projects every developer should ship, with specific 2026 tech choices, concrete implementation advice, and honest guidance on what to skip.

What changed since this post was last updated (2025):Next.js 15 (released October 2024) is now the standard for full-stack React projects. Server Actions are stable and replace many traditional API routes. Async Request APIs (cookies, headers, params) are now breaking changes in v15.Socket.IO 4.8.3 (released December 2025) is the current stable version. WebTransport support and connection state recovery are production-ready.Stripe Node.js SDK v22 (API version 2026-03-25) is the current version. Embedded Checkout is now the recommended integration method for PCI compliance.Recommended full-stack default in 2026: Next.js 15 + TypeScript + Tailwind CSS + Prisma + Supabase (PostgreSQL). The T3 Stack remains a strong opinionated choice.GitHub's good-first-issue label ecosystem has matured significantly — dedicated aggregators like goodfirstissue.dev and For Good First Issue now curate thousands of beginner-friendly tasks across Python, TypeScript, Go, and more.Portfolio expectations from hiring managers have risen sharply: live demos are required (84% of employers want working apps, not just repos), Lighthouse scores above 90 are expected, and WCAG contrast compliance is now a basic bar.

TL;DR — The 5 Projects at a Glance

Project Core skills Recommended 2026 stack Difficulty
Personal portfolio site Front-end, UI/UX, SEO, deployment Next.js 15, Tailwind CSS, Vercel Beginner
CRUD application Data flow, APIs, state management Next.js 15 Server Actions, Prisma, Supabase Beginner–Intermediate
Real-time chat app WebSockets, auth, event-driven arch Node.js, Socket.IO 4.8.3, Redis adapter Intermediate
E-commerce site Full-stack, payments, admin, UX Next.js 15, Stripe SDK v22, Prisma Intermediate–Advanced
Open source contribution Git workflows, code review, teamwork goodfirstissue.dev, GitHub Varies

1. Personal Portfolio Website

Why this project still matters in 2026

Your portfolio is the first thing a hiring manager or prospective client sees. Portfolios with three strong, live projects get more interview callbacks than portfolios with twelve mediocre ones. The bar has risen: a Lighthouse score under 90, missing live demos, or WCAG contrast failures are now red flags, not polite suggestions.

Most developer portfolios blend into sameness: the same hero section, the same todo-app project, the same skills grid. The ones that land jobs either solve a real problem (a local business tool, a community resource, a niche productivity app) or demonstrate exceptional craft and taste in presentation.

What you will learn

  • HTML, CSS, and JavaScript fundamentals applied to real UI design decisions
  • Responsive web design and mobile-first layout
  • Core UI/UX principles: visual hierarchy, whitespace, type scale
  • SEO basics: semantic HTML, Open Graph tags, meta descriptions, sitemap
  • Performance optimization: image compression, lazy loading, Core Web Vitals
  • Deployment pipelines: Vercel (best for Next.js), Netlify (best for multi-framework static sites, commercial-friendly free tier), or GitHub Pages (static only, 1 GB repo cap, 100 GB bandwidth soft limit)
  • Git and version control in a real project context
  • Accessibility: WCAG contrast ratios, keyboard navigation, semantic landmarks

Key features to build

  • About section: Specific, not generic. State your specialization and what problems you solve.
  • Projects gallery: 3–5 projects max. Each entry needs a live link, a GitHub link, a short problem statement, your technical decisions, and what you learned. Screenshots alone are not sufficient — hiring managers want to click through.
  • Contact: A working form (use Resend, Formspree, or Netlify Forms for the backend) or a direct email link.
  • Optional blog: High signal-to-noise. One well-written technical post beats ten shallow ones.
  • Performance: Run Lighthouse in Chrome DevTools. Target 90+ on Performance, Accessibility, and Best Practices. Fix render-blocking scripts, oversized images, and missing alt text first.

2026 tech recommendations

  • Framework: Next.js 15 App Router for a React-based portfolio. Astro is an excellent alternative for content-heavy static sites (ships zero JavaScript by default).
  • Styling: Tailwind CSS v4 (released 2025) for rapid, consistent design. Use clamp() for fluid typography that scales across viewports without manual breakpoints.
  • Deployment: Vercel's Hobby plan (free, non-commercial). For commercial use, Netlify's free plan supports commercial projects at no cost.
  • Animation: Framer Motion for component transitions; keep it subtle. Motion for the sake of motion is noise.

Common pitfalls

  • Light gray text on white backgrounds — fails WCAG contrast; 86% of reviewed portfolios had this issue.
  • Projects without live demos — screenshots are not enough.
  • Portfolio page loads in over 2 seconds — hiring managers move on.
  • Listing every technology you have ever touched instead of showing depth in 2–3 stacks.
  • No mobile optimization — test at 360px before shipping.

Pro tips

  • Write a short case study for each project explaining the problem, your decisions, and what you would do differently now. This is one of the highest-signal things a junior developer can show.
  • Keep it updated. Stale portfolios (last commit two years ago) signal disengagement.
  • Use beginner HTML projects to warm up your front-end skills before tackling a full portfolio build.

2. CRUD Application (Task Manager, Notes App, or Mini SaaS)

Why this project matters

CRUD — Create, Read, Update, Delete — is the backbone of almost every application in existence. Building a real CRUD app teaches you data modeling, API design, state management, and the full lifecycle of a user-facing feature. It sounds simple; the details are where the learning happens.

In 2026, the standard is no longer a bare Express API and a MongoDB collection. Hiring managers expect you to understand type-safe data access, proper authentication, and deployment that does not break on the first real user. Start with a clean MVP and iterate toward production quality.

What you will learn

  • CRUD operations and RESTful API design — or Server Actions as a modern alternative in Next.js 15
  • State management (React Query / TanStack Query for server state; Zustand for client state)
  • Database schema design with Prisma ORM (type-safe, migration-based)
  • Database hosting: Supabase (free tier, PostgreSQL with a dashboard, auth built in) or PlanetScale (MySQL, serverless driver)
  • User authentication: NextAuth.js v5 / Auth.js, or Supabase Auth
  • Front-end and back-end integration patterns
  • Input validation with Zod — validate at the server boundary, not just in the browser
  • Framework: Next.js 15 with the App Router. Server Actions (stable in v15) replace traditional API routes for form submissions and mutations — dramatically less boilerplate.
  • ORM: Prisma 6 — type-safe schema, auto-generated migrations, excellent TypeScript DX.
  • Database: Supabase (hosted PostgreSQL, free tier, includes Auth and real-time). For maximum control and predictable costs, Prisma + vanilla PostgreSQL on a VPS is a valid 2026 choice.
  • Auth: NextAuth.js v5 (Auth.js) or Supabase Auth. Both integrate cleanly with Next.js 15.
  • Validation: Zod — define a schema once, infer TypeScript types from it.

Key features to build

  • Create: A form with client-side validation (React Hook Form + Zod) and server-side validation (Zod in a Server Action or API route).
  • Read: List view with pagination or infinite scroll. Implement search and filtering.
  • Update: Inline editing or a modal. Optimistic UI updates using TanStack Query's useMutation.
  • Delete: Soft delete (mark as deleted, keep the row) is more realistic than hard delete. Add undo functionality.
  • Persistent storage: Start with localStorage for a pure front-end prototype, then move to a real database.
  • Authentication (recommended): Per-user data isolation is table stakes in real products. Add it early — retrofitting auth is painful.

Suggested projects that stand out

  • A SaaS-style project manager with public pages, sign-in, an authenticated dashboard, and a simple analytics view — proves you understand routing, auth, data, and deployment together.
  • A markdown notes editor with autosave, a sidebar listing saved notes, and a live preview pane.
  • A habit tracker with streak logic and a simple calendar heatmap (GitHub contribution-style).

Common pitfalls

  • Skipping server-side validation because the client already validates — never trust the client.
  • Storing passwords in plain text. Use a proper auth library; never roll your own password hashing unless you are a cryptographer.
  • N+1 query problems — learn to use Prisma's include or select to avoid hammering the database.
  • Not handling errors in the UI — show meaningful error states, not blank screens.

3. Real-Time Chat Application

Why this project matters

A chat app is a significant step up from a CRUD app. It forces you to think about real-time data flow, event-driven architecture, concurrency, and security in ways that simple request-response apps do not. These are patterns that appear in collaborative tools, live dashboards, notifications systems, and multiplayer games — not just messaging apps.

What you will learn

  • WebSockets and the Socket.IO abstraction layer (automatic fallback to HTTP long-polling when WebSockets are unavailable)
  • Room and namespace management for private and group chats
  • Session-based and token-based authentication in a stateful context
  • Event handling and asynchronous logic at scale
  • Horizontal scaling with the Socket.IO Redis adapter (required for multi-server deployments)
  • Security: XSS prevention, CSRF protection, input sanitization, rate limiting
  • Deployment considerations for long-lived connections (sticky sessions with NGINX, WebSocket proxying)

2026 tech choices

  • Socket.IO 4.8.3 (released December 23, 2025) — current stable version. Adds WebTransport support (faster than WebSockets on HTTP/3) and connection state recovery. Use the Redis adapter if you deploy more than one server process.
  • Alternative: Ably or Pusher Channels for managed real-time infrastructure (removes operational complexity, has a generous free tier). Good for a portfolio project if you want to focus on the product logic rather than the infrastructure.
  • Backend: Node.js with Express or Fastify. Socket.IO integrates directly with both.
  • Database for message persistence: PostgreSQL via Prisma or Redis for ephemeral chat history.
  • Auth: JWT-based tokens passed during the WebSocket handshake.

Key features to build

  • Login / signup: Secure authentication. Hash passwords with bcrypt or argon2.
  • 1:1 and group chats: Private rooms and public channels with Socket.IO rooms.
  • Real-time messaging: Sub-100ms message delivery. Test with two browser tabs open simultaneously.
  • Persistent message history: Store messages in the database; load the last N messages on join.
  • User presence: Online/offline indicators and typing status (socket.emit('typing') with debounce on the client).
  • Notifications: Unread message counts per room using badges.

Architecture sketch

Client (React) ←→ Socket.IO Server (Node.js/Express)
                        ↓
                   Redis Adapter  ←→  PostgreSQL (message history)
                   (multi-node)        (Prisma ORM)

Common pitfalls

  • Not sanitizing user input before broadcasting — a single unsanitized <script> tag can XSS every connected user.
  • Storing messages only in memory — they disappear on server restart.
  • Not rate-limiting message sends — bots will flood the server.
  • Forgetting to clean up event listeners on component unmount (React) — causes memory leaks and duplicate message handlers.
  • Missing the Redis adapter when scaling to multiple processes — users on different server instances cannot message each other.

4. E-Commerce Website

Why this project matters

An e-commerce application is the most comprehensive project on this list. It requires you to handle user authentication, product data modeling, cart state, payment processing, webhook-driven order fulfillment, admin operations, and SEO — all at once. Building even a simplified version exposes you to enterprise-level concerns that most toy projects never surface.

What you will learn

  • Product catalog design: categories, attributes, inventory tracking
  • Shopping cart logic: client-side state that survives page refreshes (Zustand + localStorage or server-side cart)
  • Payment gateway integration: Stripe SDK v22 (API version 2026-03-25) with Embedded Checkout
  • Webhook-driven fulfillment: never fulfill an order based on a redirect URL; always use the checkout.session.completed webhook
  • Secure authentication and per-user data (order history, wishlists)
  • Admin panel: product management, order status updates, basic analytics
  • SEO for product pages: structured data (JSON-LD), canonical URLs, Open Graph

2026 tech choices

  • Framework: Next.js 15 App Router. Server Actions handle cart mutations cleanly without dedicated API routes. The React 19 compiler (experimental) reduces manual memoization.
  • Payments: Stripe Node.js SDK v22 with Embedded Checkout (keeps the user on your domain via iframe; Stripe handles all PCI compliance). Avoid building your own payment form unless you have specific requirements and a security audit budget.
  • Database: Prisma + Supabase PostgreSQL for product catalog, users, and orders.
  • Image optimization: Next.js 15 uses sharp automatically — no manual installation needed. Use the <Image> component for all product images.
  • Search: Start with Postgres full-text search via Prisma. Upgrade to Algolia or Meilisearch when the catalog grows.

Key features to build

  • Product listings: Category filters, search, sorting by price/rating. Pagination or infinite scroll.
  • Product detail page: Image gallery, size/variant selector, add-to-cart, stock status.
  • Shopping cart: Persistent across sessions. Update quantities, remove items, see running total.
  • Checkout flow: Shipping address → Stripe Embedded Checkout → Order confirmation.
  • Stripe webhook: Listen for checkout.session.completed to create the order record and decrement inventory. Use Stripe CLI (stripe listen --forward-to localhost:3000/api/webhooks) for local development.
  • User accounts: Login, order history, address book.
  • Admin panel: CRUD for products, order status management.
  1. Frontend calls a Server Action to create a Stripe Checkout Session.
  2. User completes payment in the Embedded Checkout iframe (stays on your domain).
  3. Stripe sends checkout.session.completed webhook to your server.
  4. Server creates the order record and deducts inventory.
  5. User sees order confirmation page.

Common pitfalls

  • Fulfilling orders on the payment redirect URL — the webhook is the only reliable signal. Redirect URLs can fail silently (user closes the tab, network drop).
  • Not verifying the Stripe webhook signature — anyone can POST to your webhook endpoint.
  • Storing Stripe secret keys in client-side code or environment variables prefixed with NEXT_PUBLIC_.
  • Not handling out-of-stock states — a customer should not be able to purchase what does not exist.
  • Building the admin panel as an afterthought — design the data model with admin operations in mind from day one.

5. Open Source Contribution

Why this project matters

Open source is the one project on this list where you read more code than you write — and that is the point. Contributing to a real, maintained project with real users teaches you to navigate unfamiliar codebases, understand existing architecture decisions, communicate through code review, and follow contribution standards that actual teams enforce.

It also gives you something no portfolio project can fully replicate: verifiable, public proof that another engineer reviewed your code and merged it. Hiring managers who look at your GitHub will see it.

What you will learn

  • Reading and navigating large, real-world codebases — a skill that is almost impossible to learn from tutorials
  • Git workflows: forking, branching, rebasing, resolving merge conflicts
  • Pull request etiquette: descriptive titles, focused diffs, responding to review feedback
  • Code review from experienced engineers who will push back if your solution is wrong
  • Documentation: writing clear PR descriptions, updating changelogs and README files
  • Automated CI/CD pipelines: most OSS projects run GitHub Actions on every PR
  • Issue tracking and project management in public

How to find your first contribution in 2026

  • goodfirstissue.dev: Curated beginner-friendly issues across Python (99 issues), TypeScript (77), Go (69), and more. Updated continuously. Featured projects include VS Code, Kubernetes, Excalidraw, Elasticsearch, and Ollama.
  • For Good First Issue (GitHub official): Aggregates issues labeled good first issue across all of GitHub.
  • First Timers Only: Issues specifically reserved for people making their very first contribution.
  • GitHub search: label:"good first issue" is:open language:typescript — filter by language, date, and repo size.
  • Tools you already use: If you use VS Code, React, Next.js, or Prisma daily, you already understand the use case. Read their CONTRIBUTING.md file first.

A practical contribution sequence

  1. Read the contribution guide before touching any code. Ignoring it is the fastest way to have your PR closed without merge.
  2. Reproduce the issue locally before writing a fix. Verify you understand what is broken.
  3. Write a small, focused diff. One issue, one PR. Do not fix unrelated things in the same branch.
  4. Add a test if the project has a test suite — most maintainers require it.
  5. Write a clear PR description: What was the problem, what is the fix, how did you test it.
  6. Respond to review feedback promptly and without defensiveness.

Types of contributions to start with

  • Documentation fixes: Typos, outdated examples, unclear instructions. Low barrier, high value to maintainers.
  • Bug fixes labeled good first issue: Scoped, well-defined, less likely to require deep architectural knowledge.
  • Adding tests: Projects with low coverage welcome new test cases and they are a great way to learn the codebase.
  • Translations: If the project supports i18n and you are bilingual, translations are almost always wanted.

Common pitfalls

  • Opening a PR without a linked issue — maintainers may be working on the same thing or have decided against the change.
  • Submitting a 2,000-line refactor as a first contribution — start small.
  • Not reading the contribution guide — every mature project has one for a reason.
  • Giving up after one rejection — feedback is the whole point. Revise and resubmit.

How to Approach All Five Projects

Decision tree: which project to start with?

  • Zero to three months of experience: Start with the portfolio site. It forces you to ship something real and gives you a home for all future projects.
  • Three to six months: Build the CRUD app. This is where you cross the line from "writing code" to "building software."
  • Six to twelve months: Add the real-time chat app. This is the first project that requires you to think about concurrency and state that changes outside the request-response cycle.
  • One year+: Tackle the e-commerce site. This is the first project that touches money, security, and multi-party data integrity simultaneously.
  • At any stage: Start contributing to open source. Even documentation fixes during month two are valuable.

Universal project practices

  • Ship an MVP, then iterate. A deployed mediocre version beats a perfect local one.
  • Document your work. Write a README with setup instructions, a screenshot, and a description of the problem the project solves.
  • Deploy live versions. Every project needs a public URL. Vercel and Netlify both offer free deployments. No public URL means it does not exist for hiring purposes.
  • Write about what you built. A short blog post explaining your decisions signals technical maturity beyond the code itself.
  • Refactor with hindsight. Revisiting old code with new knowledge is one of the highest-leverage learning activities available.
  • Show real activity. Regular commits — even small improvements and documentation updates — signal consistent engagement. Aim for some activity every week.

Common Pitfalls Across All Projects

  • No live demo: 84% of employers want to see a working application. Deploy everything.
  • Identical projects: Todo apps, weather apps, and calculators are table stakes. If that is all you have, add one project that solves a real problem you personally experienced.
  • Portfolio with 12 projects, all incomplete: Three finished projects outperform twelve half-built ones every time.
  • No mobile optimization: Test at 360px. A broken mobile layout on a portfolio site is a signal about your attention to detail.
  • Secrets in public repos: Never commit API keys, database credentials, or Stripe secret keys. Use .env files and add them to .gitignore before the first commit.
  • Not asking for feedback: Share with peers, post in relevant Discord servers or subreddits, and treat criticism as signal.

FAQ

Do I need to build all five projects?

No — but you should build the ones that expose gaps in your knowledge. If you have never handled authentication, the CRUD app and chat app are mandatory. If you have never touched payments, the e-commerce project is worth the effort even if you only build the payment flow and a basic product listing. Completeness matters less than demonstrated competency in the areas relevant to the jobs you are applying for.

Should I use a boilerplate or start from scratch?

Use a boilerplate (create-next-app, T3 Stack, etc.) for the scaffolding — that is what professionals do. The learning value is in the features you build on top of it, not in reinventing the project setup. Starting from scratch for a portfolio project is fine but rarely necessary.

What tech stack should I use if I am not a React developer?

These projects translate to any stack. Vue + Nuxt replaces React + Next.js for the full-stack JavaScript path. Django REST Framework + React or Django + HTMX for Python developers. Rails for Ruby developers. Laravel (with Laravel Reverb for real-time, released 2024) for PHP developers. The project patterns are the same; the syntax is different.

How long should each project take?

Portfolio site: one to two weeks for a solid first version. CRUD app: one to three weeks depending on scope. Real-time chat: two to four weeks. E-commerce: four to eight weeks for a feature-complete version. Open source: your first merged PR could take anywhere from one day (a docs fix) to several weeks (a real bug fix). Do not optimize for speed — optimize for depth.

What if I am applying for remote developer roles?

Remote hiring managers evaluate your portfolio more rigorously than in-office ones because they cannot rely on an in-person interview to fill in gaps. Live demos, clear README files, and code that reads well are especially important. If you are looking for vetted remote engineering opportunities, Codersera matches companies with pre-screened remote developers — the portfolio standards described here are directly relevant to what technical evaluators look for in that process.

Should I include AI-assisted code in my portfolio?

Yes, but own it. Using GitHub Copilot or Claude to scaffold boilerplate is now standard practice. What matters is that you understand every line, can explain your architectural decisions, and can debug problems when they arise. Interviewers who ask you to explain your portfolio code will reveal quickly whether you understand it or just generated it.

How do I make an open source contribution without getting ignored?

Read the CONTRIBUTING.md, comment on the issue before submitting a PR to signal intent, keep your diff small and focused, include tests, and write a clear description. Maintainers are volunteers with limited time — help them help you by making the review as easy as possible.

What is the minimum viable portfolio to get a first job?

One strong project with a live demo, a well-written README, and a clear explanation of the problem it solves — plus a clean GitHub profile with regular activity. Two or three projects is better. A portfolio with a dozen half-finished repos is worse than one with a single polished one.


References & Further Reading