KAHIBARO
Discord Login Register ☰
☰

33.3. Creating Backend Projects

Table of Contents

Starting Your Own Backend Projects

Creating your own backend projects is the fastest way to move from “I understand the theory” to “I can build real systems.” This chapter focuses on how to choose, plan, and execute projects that actually make you better, not just keep you busy.

Why Personal Projects Matter

Personal projects give you:

Important rule: Treat every serious personal project as if it is a small real-world product:
requirements → design → implementation → tests → deployment → monitoring → iteration.

Choosing the Right Project Ideas

Start Small but Complete

Your goal is not to build something “impressive” on day one. Your goal is to build something simple and finished.

Good beginner criteria:

Examples of good starter ideas:

Project TypeExample IdeaWhy It Is Good
CRUD APITask manager, notes app, contacts managerSimple, covers CRUD, auth, pagination
Simple business logicExpense tracker, budget plannerIncludes calculations and validations
Reference data APICountries and cities API, movie list APIRead-heavy, simple data model, good for caching practice
Learning toolsFlashcards API, vocabulary trainerGood for relationships and user-specific data

Avoid at the beginning:

You can do those later once you have smaller projects done.

Match Projects to Skills You Want

Pick projects that help you practice specific skills:

Skill to PracticeProject Feature to Add
REST API designClean endpoints, versioning, filters, sorting
Authentication & authorizationUser registration, login, roles (admin, user)
Databases & SQLRelational data, joins, pagination, search
Background jobsEmail sending, report generation, scheduled cleanup
CachingCache frequent reads, invalidate on update
File handlingUpload profile images or attachments
TestingUnit tests for logic, integration tests for endpoints

Pick one main learning focus per project. Do not try to learn everything at once.

Defining Clear Requirements

Before coding, write down what your project should do. Requirements can be simple but must be explicit.

Functional Requirements

These describe what the system does.

Example: “Task Management API”

You can write them as user stories:

Non‑Functional Requirements

These describe how the system behaves.

For a beginner project, keep them simple, for example:

Important rule: Never start writing code for a non-trivial project without at least a short written list of functional and non-functional requirements.

Planning the Architecture

You do not need “enterprise architecture,” but you should have a simple, consistent structure.

Decide the Stack

For a typical Python backend project:

Make this explicit in a small “stack” note for your project.

Basic Layering

Even in a small project, separate responsibilities:

Very simple example layout:

text 
project/
  app/
    api/
      v1/
        tasks.py
        users.py
    core/
      config.py
      security.py
    models/
      user.py
      task.py
    services/
      task_service.py
      user_service.py
    db/
      session.py
      base.py
    main.py

You do not have to create all these files at once. You can start more flat and refactor as it grows.

Design the Data Model

Turn your requirements into tables or collections.

For the Task Management API:

Users table

ColumnTypeNotes
idinteger (PK)Primary key
emailtextUnique
passwordtextHashed password
is_adminbooleanRole flag
created_attimestampAuto set

Tasks table

ColumnTypeNotes
idinteger (PK)Primary key
user_idinteger (FK)References users.id
titletextRequired
descriptiontextOptional
statustextenum: todo, in_progress, done
due_datedateOptional
created_attimestampAuto set

Draw a quick diagram in a note or a document. This prevents a lot of later confusion.

Important rule: Always design your core entities and relationships before writing code that uses them.

Designing the API

Even for a simple project, design the API endpoints up front.

Example Endpoint Design

For the Task Management API:

MethodPathDescriptionAuth requiredNotes
POST/auth/registerRegister new userNoTakes email, password
POST/auth/loginLogin and get access tokenNoReturns JWT or similar
GET/users/meGet current user infoYes
GET/tasksList tasksYesFilter by status, search by q
POST/tasksCreate taskYes
GET/tasks/{task_id}Get single taskYesOnly owner or admin
PUT/tasks/{task_id}Replace taskYes
PATCH/tasks/{task_id}Partially update taskYesOptional but nice
DELETE/tasks/{task_id}Delete taskYes

Even a small table like this acts as a mini-contract for what you will build.

Request and Response Models

Define example JSON bodies and responses.

Create task request:

json 
{
  "title": "Buy groceries",
  "description": "Milk, eggs, bread",
  "status": "todo",
  "due_date": "2026-09-01"
}

Task response:

json 
{
  "id": 1,
  "title": "Buy groceries",
  "description": "Milk, eggs, bread",
  "status": "todo",
  "due_date": "2026-09-01",
  "created_at": "2026-08-28T10:00:00Z"
}

These examples help you structure your Pydantic models or serializers later.

Building Incrementally

Do not try to build everything at once. Use small, clear steps.

Step‑by‑Step Roadmap Example

For the Task Management API:

  1. Project skeleton
    • Initialize Git repository.
    • Create minimal FastAPI app with /health endpoint.
    • Add basic requirements file.
  2. Database setup
    • Configure SQLAlchemy.
    • Create User and Task models.
    • Create initial migration and database (using Alembic, or simple create for first project).
  3. Auth basics
    • Implement registration endpoint.
    • Implement login endpoint that returns a token.
    • Protect a simple /users/me endpoint.
  4. Tasks CRUD
    • Implement POST /tasks.
    • Implement GET /tasks for current user.
    • Implement GET /tasks/{id}.
    • Implement PUT / DELETE /tasks/{id} with ownership check.
  5. Filtering and pagination
    • Add status filter and search q parameter.
    • Add pagination with limit and offset or page and page_size.
  6. Validation and error handling
    • Add request validation rules.
    • Standardize error responses.
  7. Tests
    • Add basic tests for auth and tasks endpoints.
  8. Documentation and cleanup
    • Ensure OpenAPI docs are clear.
    • Refactor code into modules, fix naming, remove dead code.

Each step should be small enough that you can complete it in 1 or 2 sessions.

Important rule: Always aim to keep the project in a “working state.” Do not break everything for days. Implement features in small, testable slices.

Using Git Effectively

For every project, treat Git as part of your skill set, not an afterthought.

Basic Git Practices for Projects

Example commit history for Task Management API:

Commit messageWhat changed
init FastAPI app and health endpointBasic app, main.py, first dependency config
add User and Task modelsSQLAlchemy models, database session
implement user registration/auth/register, Pydantic models, hashing
add login and JWT token generation/auth/login, token creation, settings config
add create and list tasks endpoints/tasks GET/POST, service layer
add ownership checks for task updatesAuthorization logic for tasks
add basic tests for auth and taskspytest config and first tests

This timeline tells a story that interviewers can follow and you can review later.

Writing Minimal but Useful Tests

Testing is covered in its own section in this course. Here we focus on what is specific to personal projects.

What to Test First

Start with:

For the Task Management API:

Even 5 to 10 tests already make your project more professional and reliable.

Keeping Tests Practical

You do not need 100% coverage. Aim for:

Documenting Your Projects

Documentation is a big part of making your project understandable to others and to future you.

The README

Every project should have a README.md at the root. For a simple backend, include:

  1. Project description
    • “Task Management API built with FastAPI and PostgreSQL.”
  2. Features
    • “User registration and login (JWT auth).”
    • “Create, list, update, delete tasks.”
    • “Filter and search tasks.”
  3. Tech stack
    • “Python, FastAPI, SQLAlchemy, PostgreSQL, Alembic, pytest, Docker.”
  4. Setup instructions
    • How to clone the repo.
    • How to create virtual environment.
    • How to set environment variables.
    • How to run migrations.
    • How to start the server.
  5. Usage
    • Example curl commands for main endpoints.
    • Link to Swagger UI (/docs).
  6. Future improvements
    • “Add email notifications.”
    • “Add due date reminders.”
    • “Add admin panel.”

API Documentation

With FastAPI, you get OpenAPI docs. Make them nicer by:

You can also add a simple markdown file docs/api.md with:

Deploying Your Projects

A project that runs only on your computer is good. A project that runs online is better.

Minimal Deployment Goal

For each serious project, try to:

Example deployment path:

  1. Create Dockerfile and docker-compose.yml.
  2. Run app and database locally with Docker.
  3. Push image to container registry.
  4. Deploy to a cheap VPS or a managed platform.
  5. Configure HTTPS and domain for at least one project.

You do not need to do this for every experiment, but do it for the more polished projects that you will show to others.

Reusing Patterns Across Projects

As you build more projects, do not start from zero every time. Create your own “project template” mentally or in code.

Patterns to reuse:

For example, you can have a fastapi-template repository with:

Then for each new project:

  1. Copy or clone that template.
  2. Rename package and project.
  3. Remove example endpoints.
  4. Start implementing new business logic.

This speeds you up and builds consistency between projects.

Growing Project Complexity Over Time

You do not need one “huge” project. It is better to build multiple projects of increasing complexity.

Possible progression:

  1. Project 1: Notes API (no auth, SQLite)
    • Simple CRUD.
    • Focus on REST and database basics.
  2. Project 2: Task Manager (auth, PostgreSQL, tests)
    • User accounts.
    • Roles (admin / user).
    • Basic tests.
  3. Project 3: URL Shortener (Redis, rate limiting)
    • Simple business logic.
    • Caching.
    • Rate limiting.
  4. Project 4: Simple E-commerce backend (cart, orders)
    • Multiple entities, relationships.
    • Payments simulation (no real gateway at first).
    • Background processing for order emails.
  5. Project 5: Real “portfolio” app
    • Best of everything you learned.
    • Fully documented and deployed.

Each new project reuses lessons from previous ones and adds one or two new major concepts.

Learning from Your Own Code

Every project is also a learning record.

After Finishing a Project

Ask yourself:

You can do a simple “postmortem” document:

text 
Project: Task Management API
What went well:
- Clear endpoints
- Simple data model
What went wrong:
- Mixed business logic in API layer
- Poor test coverage at the beginning
Improvements for next project:
- Introduce service layer earlier
- Write tests sooner
- Plan error responses up front

This is how professionals improve across projects.

Turning Projects into Portfolio Pieces

When you have a few solid backend projects:

This connects directly to the “Building a Portfolio” chapter and will be very useful when you prepare for interviews.

Key checklist for a strong backend project:

  • Clear requirements and scope.
  • Simple but explicit data model.
  • Thoughtful API design.
  • Clean Git history.
  • Basic tests for critical features.
  • Good README and API docs.
  • At least one deployed or Dockerized version.
    Even if the project is small, this combination is what shows you can think and work like a backend engineer.

By following this approach for each new project, you will steadily turn your backend knowledge into real, demonstrable skills.

Views: 9

Comments

Please login to add a comment.

Don't have an account? Register now!

© 2025 Kahibaro
Visitors: 3491 / 24h
Impressum / Imprint
Datenschutz / Data Policy