Create a Django application by connecting a small data model to a view and a URL, then checking that one meaningful record reaches the browser. Keep the first flow narrow enough to explain end to end. Use the documentation for your installed version and a separate local project so each result has an identifiable cause.
A useful first application can answer a simple business question without attempting a complete operational system. The hypothetical example here is a read-only list of service requests with short subjects. Its purpose is to make the relationship between a database record and an HTTP response visible. Additional requirements can then be assessed against something concrete.
The technical references are Django’s official 5.2 tutorial, parts one and two, retrieved on 24 October 2026. Match the versioned documentation to your environment. For broader project scoping, see web development and business systems.
What belongs in the project and what belongs in the app?
Django describes a project as configuration and apps for a particular website. A project can contain multiple Django apps. The first tutorial makes this distinction explicit. Choose a project name for the site configuration and an app name for the bounded function, so that the settings package and the service-request code have separate, understandable jobs.
Django’s startapp command generates an app’s basic directory structure. In a fresh local tutorial project, create an app named requests_demo alongside manage.py. The name is deliberately specific and avoids confusing the example with an installed HTTP client package. Keep a note of the actual project directory before running any command.
python -m django --version
python manage.py startapp requests_demo
The first command provides the installed version to compare with the tutorial. The second assumes that the project already exists and that the shell is in the directory containing its manage.py. If you are starting from nothing, follow the official tutorial’s startproject section first, then return to this bounded app exercise.
Django’s tutorial uses an HttpResponse for its first view. Start with a static response if you need to isolate URL routing before introducing the model. Once the route can return a short message, add the data-dependent response below. This staged approach makes it easier to identify whether a failure concerns imports, routing or database access.
How should the first record be represented?
Django models subclass django.db.models.Model. The second tutorial describes model classes and the fields that supply their database information. For this exercise, use a single field so that the first working flow has a clear input and output.
from django.db import models
class ServiceRequest(models.Model):
subject = models.CharField(max_length=120)
The chosen field length is an illustrative design value for this exercise. Agree real limits from the intended data and interface when designing an actual application. Give the field a meaningful name and keep sensitive personal information out of the sample record.
Django’s default database configuration uses SQLite. Retain the tutorial configuration for the isolated exercise unless you have a reason to test another supported database. Record the configured database before applying changes so that a developer can explain where the sample record will be stored.
Django records model changes in migration files through makemigrations. Django’s sqlmigrate prints migration SQL without applying it. Django’s migrate applies unapplied migrations to the configured database. Treat these as separate steps: register the app in INSTALLED_APPS, generate the migration, inspect it and then apply it to the local exercise database.
python manage.py makemigrations requests_demo
python manage.py sqlmigrate requests_demo 0001
python manage.py migrate
Keep the generated migration file with the example’s source when reviewing the exercise. If the displayed operation does not match the intended model, resolve the discrepancy before continuing. The aim is to understand the change, rather than repeat commands until the browser happens to display something.
How does the record reach the browser?
Create a view that reads the model and returns its subjects as plain text. This code is an original proposed exercise assembled from the tutorial’s model, query and response concepts; it has not been executed as part of authoring this article.
from django.http import HttpResponse
from .models import ServiceRequest
def index(request):
subjects = [item.subject for item in ServiceRequest.objects.all()]
text = "\n".join(subjects) or "No sample requests yet."
return HttpResponse(text, content_type="text/plain")
Then connect that view to the app’s URL configuration. Django’s include function references another URL configuration. Use it from the project so that the app owns its internal route while the project owns where the app is mounted.
from django.urls import path
from . import views
urlpatterns = [path("", views.index, name="request-index")]
In the project’s urls.py, add the import for include and add path("requests/", include("requests_demo.urls")) to the existing urlpatterns. Preserve the project’s other routes. The proposed local path for the exercise is /requests/, which should initially show the empty-state text.
Django’s manage.py shell loads the project’s settings context. Open it in the exercise directory and add a fictional record through the model API:
from requests_demo.models import ServiceRequest
ServiceRequest.objects.create(subject="Sample request A")
Exit the shell and refresh the local route. Compare the displayed subject with the saved sample. If there is an error, retain the relevant traceback and inspect the failing layer instead of adding unrelated configuration changes.
| Layer | Intended responsibility | Proposed evidence |
|---|---|---|
| Project settings | Activate the example app and select its database | App entry and database configuration |
| Model | Represent the request subject | Model definition and generated migration |
| Database change | Create the intended storage structure | Reviewed SQL and migration result |
| View | Read records and produce the response | View code and observed response body |
| URL configuration | Route the local request to the view | Project include and app route |
| Sample data | Provide a recognisable input | Saved fictional subject and browser output |
Use the table to identify a failing boundary. A response from the development server establishes less than a complete, data-backed flow; check the particular record as well.
Original first-flow diagnostic sheet
Write the expected empty-state response before inserting a record. Request the local route and capture the observed body. Next, add Sample request A through the shell, request the same route and record the result. Keep the command, database context and URL with each observation so another developer can repeat the exercise.
Add a second fictional subject and check that the view reflects the data. This example does not specify ordering, so assess the presence of the expected subjects rather than inventing an order requirement. If ordering matters to the intended product, make that a separate requirement and verify the relevant implementation.
Finally, explain the complete route aloud: project URL, app URL, view, model query and response. Ask which part would change if the business wanted another field or a different presentation. This turns a small working example into a useful scoping conversation. The Django tutorial reserves its development server for development. Development-server boundary. Treat deployment as a separate design and configuration review.
For the next requirements discussion, bring the model, migration and diagnostic observations. Get started with the business question the application should answer and the decisions the first flow has exposed.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.