Modeling the Domain

Model the domain, not the screens. A schema shaped around the pages you happened to draw will fight you the moment a page changes.

Name the things that exist in your problem, the facts about each, and how they relate. From the SQL course: one table, one kind of thing, and you must be able to say what one row of it represents in a sentence.

The decisions that are expensive to reverse. Everything else can be changed cheaply. These cannot.

A custom user model, which Django's own documentation says to create before your first migration.

Whether a relationship is one-to-many or many-to-many, because changing it later means migrating data, not just schema.

What is stored versus what is derived, because a derived value stored by accident becomes a value that disagrees with its source.

What on_delete should be for each relationship, which is a decision about your data, not a formality.