Your First App
The taskflow_project we created holds settings and configuration, but zero actual
task-management logic — that's exactly what a Django app is for. In this
lesson we create TaskFlow's first app, tour the files it generates, and register it so Django
actually knows it exists.
Creating the App
From the same folder as manage.py, with the virtual environment still active, run:
python manage.py startapp taskflow
This creates a new folder named taskflow sitting alongside
taskflow_project, pre-populated with the standard set of files every Django app
starts with.
Touring the Generated App Folder
taskflow/
├── migrations/
│ └── __init__.py
├── __init__.py
├── admin.py
├── apps.py
├── models.py
├── tests.py
└── views.py
| File / Folder | What it's for |
|---|---|
models.py | Where Task, Project, and Tag will be defined as Python classes — covered fully in Models & Migrations |
views.py | Where the logic for handling requests lives — things like task_list, covered in Function-Based Views |
admin.py | Where models get registered so they show up in Django's auto-generated admin site — covered in The Django Admin: Basics |
apps.py | A small configuration class describing the app itself, mostly left untouched in everyday development |
migrations/ | A folder that will fill up with auto-generated files tracking every change ever made to your models' database structure — also covered in Models & Migrations |
tests.py | Where automated tests for this app live — covered in Testing: Unit Tests |
Notice what's not here yet: there's no urls.py and no templates/
folder. Unlike the files above, Django doesn't generate these automatically for a new app —
we'll create both ourselves, starting with urls.py in the very next lesson.
Registering the App in INSTALLED_APPS
Creating the taskflow folder does not automatically make Django aware of it. Open
taskflow_project/settings.py and add it to the INSTALLED_APPS list:
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'taskflow', # our new app
]
taskflow's models (so migrations won't pick
them up), its templates (so template lookups will fail), or its admin registrations (so nothing
will appear in the admin site) — all without necessarily throwing an obvious error pointing
you back to this missing line.
Why Keep Apps Focused on One Feature Area
It's tempting, especially early on, to dump every bit of logic into one big app. Django's design actively encourages the opposite: each app should be responsible for one coherent feature area, reusable and understandable largely on its own. A more mature version of TaskFlow, for example, might eventually split into several apps rather than one giant one:
taskflow— tasks, projects, and tags: the core feature this whole track buildsaccounts— user registration, profile management, anything beyond Django's built-in authbilling— subscription plans or payment handling, if TaskFlow ever became a paid product
This track keeps everything inside the single taskflow app for simplicity, since our
goal is learning Django's concepts clearly rather than practicing large-scale project
organization — but it's worth knowing this convention exists before you start structuring a
real project of your own.
What We'll Build Into This App
With the app created and registered, the rest of this track fills it in piece by piece:
- Models for
Task,Project, andTag, plus the relationships between them - Views, both function-based and class-based, for listing, creating, editing, and completing tasks
- Templates for actually rendering TaskFlow's pages in the browser
- Forms for creating and editing tasks and projects through the browser rather than the admin
- Eventually, a full REST API for TaskFlow using Django REST Framework, later in the track
taskflow app's own urls.py and connect it to the project.