32.1. Planning the Application

Table of Contents

Defining the Problem Before Writing Code

Before you open your editor or create a Git repository, you need to know exactly what you are building and why. Planning your final project as if it is a real-world product will guide your technical choices later in the course and reduce expensive refactors.

In this chapter you will not design the database, API, or deployment. You will focus on the problem space and the shape of the application at a high level. Think of this as writing the “product brief” for your backend.

Clarifying the Purpose of the Application

Every good backend exists to solve a concrete problem for real users. Start by answering three questions in plain language.

1. Who are the users?

List the main kinds of people or systems that will use your application. These are your “personas.” For each, describe their goals, not their technical details.

Example for a project management backend:

Regular User

Wants to create tasks and track their progress.
Needs to see only their own projects and tasks.

Manager

Needs to see tasks for a whole team.
Needs basic reporting, for example how many tasks are overdue.

Admin

Manages users and permissions.
Can deactivate accounts and view system-wide data.

You might also have machine users, such as:

Mobile App Client

Calls your API to display data on iOS or Android.

Webhook Consumer or Producer

Either sends events to your system or receives events from it.

Keep this list short. Two to four personas is usually enough for a focused final project.

2. What problem are you solving?

Write a short paragraph that describes the problem in everyday language.

Example:

Small teams use chat and spreadsheets to manage tasks. Work gets lost, people forget deadlines, and no one has a clear picture of progress. We want a simple backend that stores projects, tasks, and comments, and exposes a clean REST API that any frontend can use.

Avoid any mention of specific technologies at this stage. You are describing what you solve, not how.

3. What is in scope and out of scope?

Define the borders of your project. Many projects fail because they try to do too much.

Create two lists:

In scope (MVP):

User registration and login
CRUD for core entities (for example tasks, products, orders)
Simple authorization rules
Basic search or filtering
Minimal admin actions

Out of scope (can be future work):

Complex analytics dashboards
Full-text search across all data
Real-time updates with WebSockets
External payment gateway integration (unless your project is specifically about payments)

Clearly defining what you will NOT build is as important as defining what you will build. It keeps your project realistic and finishable.

Defining Core Features and Use Cases

Once you know the problem and users, move to concrete actions. A use case describes how a user interacts with your system to achieve a goal.

Identifying Core Features

Your core features should map to your problem statement. For a typical backend-heavy application, you might have features like:

User management
Authentication and authorization
Domain-specific resources (for example tasks, products, orders)
Comments or notes
Basic reporting or summaries
File uploads (optional, if they are important to your idea)
Notifications or background jobs (only if they support your main flows)

Pick a small set that represents real value. For example, for an e-commerce style backend:

Feature	Description
Product catalog	Store and retrieve product details
Shopping cart	Add, update, and remove items from a cart
Orders	Place orders and track their status
User accounts	Register, login, manage profile
Basic admin operations	Create or update products, view user orders

Writing Use Cases

A simple template:

As a <type of user>, I want to <do something> so that <achieve a goal>.

Examples:

“As a registered user, I want to create a new task so that I can remember what I need to do.”
“As a manager, I want to see all tasks assigned to my team so that I can monitor progress.”
“As an admin, I want to deactivate a user account so that I can remove access when employees leave.”

Make a short list of the most important use cases. You will translate these into endpoints, database tables, background jobs, and so on in later chapters.

Grouping Use Cases into Modules

Group related use cases into logical modules. This will later influence your backend architecture and project structure.

Example grouping:

Module	Related Use Cases
Auth	Register, login, logout, reset password
Users	View and update profile, change email, list users (admin)
Projects	Create project, list projects, archive project
Tasks	Create task, assign task, change status, list tasks
Comments	Add comment, list comments on a task

These modules will often become Python packages, FastAPI routers, and database schemas.

Non-Functional Requirements

Non-functional requirements describe how well your system should work, not what it does. They strongly influence your backend design and your production setup.

Performance

Decide on reasonable performance expectations. For a learning project you do not need extreme scalability, but you should still define realistic targets:

Target API response time for normal operations, for example < 300 ms for most endpoints.
Expected number of concurrent users, for example “tens” or “hundreds,” not millions.
Data size expectations, for example “thousands of records” or “up to 1 million rows in the main table.”

These numbers do not have to be perfect. Their main role is to guide decisions like caching, indexing, and background jobs.

Reliability and Availability

Define how important uptime is and what failure looks like.

Is short downtime acceptable during deployments?
Is losing a few seconds of data acceptable if the database fails?
Do you need daily automated backups?

Example for a student project:

Acceptable downtime during deployments.
Daily PostgreSQL backups are required.
No intentional data loss, but some rare failures during development are acceptable.

Later, in the “Production Backend Engineering” and “Deployment” chapters, these expectations will influence your choice of backup strategy and rollout method.

Security and Compliance

You will deal with authentication, authorization, and basic web security. For planning the application, decide:

What kind of data will you store?

Only emails and hashed passwords?
Addresses, payment-related info, or other sensitive data?

Who must be able to access what?

Users can access only their own data.
Admins can access more, but with strict auditing (if you choose to implement it).

For your final project, avoid real payment data and highly sensitive personal data. Focus instead on implementing secure patterns for common data such as usernames, email addresses, and internal domain data.

Mapping Users to Responsibilities

Once you have personas and modules, sketch who can do what. This is not yet a full authorization system, but a simple matrix of responsibilities.

Action	Regular User	Manager	Admin
Register account	Yes	Yes	No
Login / Logout	Yes	Yes	Yes
Create task	Yes	Yes	No
Assign task to another user	No	Yes	Yes
View own tasks	Yes	Yes	Yes
View team tasks	No	Yes	Yes
View all users	No	No	Yes
Deactivate a user	No	No	Yes

Later, this matrix will feed directly into your authorization rules and tests.

Planning the Project Phases

Your final backend will be built in stages. Planning these stages early makes your work more manageable and easier to debug.

A simple phase breakdown:

Phase 1, Core domain and authentication

Define core entities conceptually (no schema details yet).
Implement user registration and login with basic validation.
Implement simple CRUD for the main resource, for example tasks, products, or orders.

Phase 2, Validation and authorization

Add stricter input validation.
Enforce ownership rules, for example users can access only their own resources.
Add simple role-based access, for example admin endpoints.

Phase 3, Background work and integrations

Add background jobs, for example sending emails or cleaning up old data.
Integrate Redis if needed.
Add file storage integration if your project uses uploads.

Phase 4, Production hardening

Add logging and monitoring endpoints such as health checks.
Improve error handling and error responses.
Prepare configuration for multiple environments.

You do not need to implement all phases at once. For now, it is enough to decide a rough order so that you do not overcomplicate the first iteration.

Writing a Short Project Specification

Bring everything together in a short written spec, one to two pages. This is your reference document for the rest of the final project.

A simple structure:

Overview

One paragraph problem statement.
One paragraph summary of the solution.

Users

List of personas with their goals.

Scope

In-scope features for the final project.
Out-of-scope features that you explicitly will not build.

Core Features and Use Cases

Short list of modules.
Key use cases in “As a … I want to … so that …” format.

Non-Functional Requirements

Performance targets.
Availability expectations.
Security considerations, at a high level.

Phases

A simple step-by-step plan of what you will implement first, second, and so on.

Do not skip writing this specification. A few hours of clear planning can save you many days of confused coding and refactoring.

Keep this document in your repository, for example as docs/specification.md. Update it only when the product changes, not for every technical detail.

How This Planning Connects to Later Chapters

The work you do here will drive specific technical decisions in the coming chapters:

Designing the Architecture will use your modules and non-functional requirements to pick patterns like layered architecture and dependency injection.
Designing the Database will transform your core features and use cases into tables and relationships.
Building the REST API will map your use cases to actual endpoints and response models.
Authentication and Authorization will implement the user and role responsibilities you defined here.
Performance, Security, and Deployment will use your non-functional requirements as the success criteria.

By taking planning seriously now, you give yourself a clear target for the rest of the final project and practice how real backend engineers structure their work before they start writing code.