Django App Structure Explained: 7 Files You’ll Actually Use

The first app I ever created in Django was called blog. I remember running python manage.py startapp blog, watching a new folder pop up, and thinking — okay, now what? I had just gone through the pain of understanding the project structure, and now here was a whole new set of files sitting inside this smaller folder, waiting to confuse me all over again.

So let’s go through it properly this time. If you’ve already read my post on the Django project structure, this one picks up right where that left off — the moment you create your first app inside that project.

Project vs. App — A Quick Reminder

Before diving into the files, it’s worth repeating this distinction because it trips people up constantly: a project is the whole website. An app is one feature of it — a blog, a store, a comments system, whatever. One project can hold many apps. That’s the whole design philosophy behind Django, and it’s why the folder you’re about to explore looks so different from the project folder.

Django App Structure Explained The Command That Creates an App

python manage.py startapp blog

Run this from inside your project’s root folder — the same level as manage.py. Django creates a new folder named blog, sitting right next to manage.py, not inside your settings package. That trips up a lot of beginners who expect it to nest inside the inner project folder. It doesn’t.

Here’s what you’ll find inside:

blog/
    migrations/
        __init__.py
    __init__.py
    admin.py
    apps.py
    models.py
    tests.py
    views.py

1. models.py — Where Your Data Lives

This is the file I open first, every single time. models.py is where you define your database tables using plain Python classes. If I’m building a blog, my Post model might look like this:

python

from django.db import models

class Post(models.Model):
    title = models.CharField(max_length=200)
    content = models.TextField()
    created_at = models.DateTimeField(auto_now_add=True)

Django takes this Python class and translates it into an actual database table behind the scenes. You never have to write raw SQL for basic operations — that’s one of the things that hooked me on Django early on.

2. views.py — The Logic Behind Every Page

Once you have data, you need something to decide what gets shown to a visitor. That’s views.py. A simple view might just fetch all blog posts and pass them to a template:

python

from django.shortcuts import render
from .models import Post

def post_list(request):
    posts = Post.objects.all()
    return render(request, 'blog/post_list.html', {'posts': posts})

Every page on your site that shows dynamic content is going to route through a view like this eventually.

3. admin.py — Your Free Dashboard

This file genuinely surprised me the first time I understood it. By registering a model here:

python

from django.contrib import admin
from .models import Post

admin.site.register(Post)

You instantly get a full admin interface at /admin/ where you can add, edit, and delete blog posts through a browser — no extra code required. I still think this is one of Django’s most underrated features for beginners.

4. apps.py — Quiet Configuration

This file defines a small config class for the app itself. Django uses it internally to identify and load the app correctly. You’ll rarely need to edit it, but it’s good to know it exists and roughly why.

5. tests.py — A Placeholder for Good Habits

Django creates this file empty on purpose, almost like a nudge. It’s where you’ll eventually write tests to check that your models and views behave correctly. I ignored this file for my first few projects — I don’t recommend doing the same once your projects grow past the beginner stage.

6. migrations/ — Tracking Every Change

Every time you add or change a field in models.py and run:

python manage.py makemigrations

Django creates a new file inside this folder describing exactly what changed. Then python manage.py migrate applies those changes to your actual database. I think of this folder as a changelog for your database structure — it’s incredibly useful once you’re working with a team or deploying updates.

7. init.py — Same Job, Different Folder

Just like in the project folder, this file is empty and simply tells Python to treat blog as a package. Nothing to configure here.

The Step Everyone Forgets

Creating the app with startapp does not automatically activate it. You still need to open settings.py and add it to INSTALLED_APPS:

python

INSTALLED_APPS = [
    ...
    'blog',
]

I’ve lost count of how many times a student has messaged me confused about why their model isn’t showing up in migrations, only to realize this one line was missing.

How Project and App Files Work Together

Once your app is registered, everything connects: urls.py in your project routes requests to views in your app, those views pull data through models.py, and admin.py gives you a way to manage that data without writing a single form by hand. It’s a small, tidy loop once you see it laid out this way.

If you haven’t gone through it yet, my earlier post on the Django project structure covers the outer layer this app now plugs into. And for anything deeper on apps specifically, the official Django documentation is worth a read.

Final Thoughts

A Django app might look like just another folder of unfamiliar files at first, but each one has a clear, narrow job. models.py defines your data, views.py decides what’s shown, admin.py gives you a dashboard for free, and migrations/ quietly tracks it all over time.

Go create a throwaway app right now, add one simple model, and register it in the admin panel. Seeing it work end to end is what finally made this click for me.

Full Course