Skip to content
BSWEN
Blog

Are Todo, Blog, and URL Shortener Portfolio Projects Still Worth Building in 2026?

Cowrie
Cowrie
Dev @ Bswen

Three-phase roadmap: Phase 1 Project Core, Phase 2 Production Polish, Phase 3 Job Prep

Problem

I asked myself the same question many junior developers ask on r/Python: are Todo, Blog, and URL Shortener projects still worth building in 2026? I had finished a Todo API in FastAPI + PostgreSQL + SQLAlchemy + Docker, and I worried it blended in with the hundreds of other junior portfolios using the exact same stack and the exact same domain.

Every tutorial tells you to build one of the “classic six.” After building two of them, I started to wonder if recruiters had stopped reading them entirely.

Purpose

This post answers whether the classic beginner backend projects are still worth your time in 2026. The key point is yes, but only as a quick learning exercise, not as the final portfolio piece. The right move is a two-phase build: a throwaway classic to learn the stack, then one real-domain project on top of the same code.

Environment

  • Python 3.11
  • FastAPI
  • PostgreSQL 15
  • SQLAlchemy 2.0
  • Alembic for migrations
  • pytest + httpx for tests
  • Docker + docker compose

The Direct Answer

Yes, a Todo / Blog / URL Shortener project is still worth building, but only as a throwaway learning exercise, not as a portfolio piece. A finished Todo API on your resume in 2026 will not hurt you, but it will not help you either, because every other junior applicant has the same project on their GitHub.

The real value of these projects is that they let you practice FastAPI, SQLAlchemy, PostgreSQL, and Docker quickly. The mistake is treating them as a final artifact.

If you want a portfolio that stands out, build one of these classics first to learn the stack, then build one real-domain project on top of the same code so the GitHub profile tells a progression story.

The Two-Phase Build

Three-phase roadmap: Phase 1 Project Core, Phase 2 Production Polish, Phase 3 Job Prep

Here is the mental model that actually answers the question:

Phase 1 vs Phase 2 portfolio build
Phase 1 - Classic CRUD (private repo, 2-3 days)
  - Todo / Blog / URL Shortener
  - Goal: learn the stack
  - Audience: yourself
  - On your resume? No


Phase 2 - Real-domain backend (public repo, 1-3 weeks)
  - HR / Clinic / Warehouse / Internal tool / Auth service
  - Goal: demonstrate production hygiene
  - Audience: recruiters and interviewers
  - On your resume? Yes

The split matters. Without it, either you never learn the basics, or you spend weeks polishing a project that will not differentiate you.

Why the Classics Blame

The “classic six” projects exist for a reason. They are the smallest possible CRUD apps that still let you wire together a realistic backend stack: a web framework, an ORM, a database, and an HTTP layer. They are the fastest way to learn, which is why tutorials default to them.

But there is a gap between “good for learning” and “good for a portfolio,” and most candidates do not see the gap. A hiring manager skims 50 to 200 GitHub profiles per role. After the third Todo API, they have stopped reading. Not because Todo APIs are bad, but because they are all the same: one Task table, four endpoints, no auth, no tests, no migrations, no Docker.

The Solution: A Two-Phase Build

Phase 1 - Learn the stack with a classic (2 to 3 days, private repo is fine)

Pick one of the six and build it cleanly. Use this project to:

  • Wire FastAPI, SQLAlchemy, PostgreSQL, Alembic, and Docker together for the first time.
  • Practice Pydantic v2 schemas, dependency injection, and basic auth.
  • Write a few tests with pytest and httpx.AsyncClient.
  • Get a green CI pipeline.

This project will never be on your resume. That is fine. Its job is to teach you the moving parts.

Phase 2 - Build one “real” project for the portfolio (1 to 3 weeks, public repo)

Take the muscle memory from Phase 1 and apply it to a domain that has real rules: HR, clinic, warehouse, internal tool, auth service. Same stack, but a domain that forces non-trivial SQL, transactions, roles, and state machines.

The result is a GitHub profile that shows progression, not just one polished repo. Recruiters who click through see the polished one first; engineers who dig deeper see the learning one and understand your trajectory.

A “Phase 1” Classic, Kept Small

Here is what a Phase 1 endpoint should look like. It is deliberately tiny, but it already shows the layered structure:

app/routers/tasks.py
from fastapi import APIRouter, Depends
from sqlalchemy.ext.asyncio import AsyncSession
from app.deps import get_session
from app.schemas import TaskIn, TaskOut
from app.repositories import TaskRepository


router = APIRouter(prefix="/tasks", tags=["tasks"])


@router.post("", response_model=TaskOut, status_code=201)
async def create_task(payload: TaskIn, session: AsyncSession = Depends(get_session)):
    repo = TaskRepository(session)
    return await repo.create(payload)

This is the right size for a learning project: routers, schemas, repositories, and dependency injection are all there, but the domain is one table. Spend two days, then move on.

A “Phase 2” Signal, the Same Author Writing the Real Thing

Here is the same author a few weeks later, applying the same patterns to a real domain (inventory reservations):

app/services/booking.py
async def reserve_inventory(
    session: AsyncSession,
    sku: str,
    quantity: int,
    order_id: UUID,
) -> Reservation:
    async with session.begin():
        stock = await session.execute(
            select(InventoryRow).where(InventoryRow.sku == sku).with_for_update()
        )
        row = stock.scalar_one()
        if row.available < quantity:
            raise InsufficientStockError(sku=sku, requested=quantity, available=row.available)
        row.available -= quantity
        reservation = Reservation(order_id=order_id, sku=sku, quantity=quantity)
        session.add(reservation)
    return reservation

The two snippets together tell a reviewer: this person learned the basics, then leveled up. That is the whole point.

Why This Matters

A portfolio is not a list of finished products, it is evidence of how you think. A single complex project is better than six shallow ones, but a single complex project plus evidence of how you got there is the strongest possible signal for a junior.

Recruiters do not expect a junior to have shipped a SaaS. They expect the junior to demonstrate that they understand layered architecture, transactional data, auth, and deployment.

Common Mistakes

  • Skipping the classics entirely and trying to build a “real” project without ever wiring a basic CRUD app. You will get stuck on tooling instead of learning the domain.
  • Putting the classic on your resume as a finished portfolio piece. It will not differentiate you.
  • Overbuilding the classic (Todo API with tags, sharing, real-time updates, etc.). Time spent on a Todo is time stolen from the real project.
  • Never deleting the classic. Make the Phase 1 repo private or archive it so the public profile is clean.

Summary

In this post, I showed why Todo, Blog, and URL Shortener projects are still worth building in 2026, but only as fast learning exercises, not as final portfolio pieces. The key point is the two-phase build: a quick classic to learn the stack, then one real-domain project to demonstrate production hygiene. That progression answers the original question directly: they blend in, so use them to learn, not to ship.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments

Tags: