Django is a Python open source Web Framework that is free and can build complex web apps rapidly with less code and a clean and pragmatic design. It follows a high-level model view template architectural pattern. Although Django was created in 2003 it was in 2005 that it was publicly released. Django was built by skilled and experienced developers allowing you to write your apps without focusing on the problems of web development like common security hassles among others.
When you are building your website with Django several things have to be kept in mind. But the three most important things are stated below

Be Careful about Defining and Organizing  ‘Apps’

The concept of  ‘Apps’  in Django is defined as a Python package with some set features. The model migrations for each app are tracked by Django separately. In case of a foreign key linking model, the migration system of Django across different apps will create a dependency graph to allow migrations to run in the right order. But this is not always the case as there can be errors and complex dependencies if there are many apps. A developer starting a Django project should ignore the concept of many apps but just stick to a single app and go ahead to organize a codebase. But if you want to go for separate applications make sure to define them to minimize any dependencies between the apps. You can follow the  ‘Getting Started’  tutorial to create a top-level app of the project directory

Steer Away from GenericForeignKey

Avoid using GenericForeignKey if possible as you will lose database features and data integrity features. The best solution is to use separate tables, leveraging abstract base models for code reuse. GenericForeignKey allows a lot of dependency on the framework of Django that stores table identifiers in a mapping table. The table uses your app’ name and Python model class as columns to connect the Django model to the integer id that is later stored in the GFK table. Manual patching is required if models are moved between apps and renamed. If you have one common table for mapping GFK, things will become more complicated as it will become difficult to move tables into distinct services or databases. Similarly, the table identifiers should be defined and named explicitly.

Keep Migrations Safe Reducing Friction

If you are using Django’s migration system to migrate and manage your schema you need to ensure that your migrations are safe and when applied will not cause downtime. Any issue regarding migration can be avoided if you run migration after deploying the code. But it is best not to commit multiple migrations before deployment. You need to watch for tables and dropping columns also. A large production database can cause unsafe operations thus locking up your tables or database leading to downtime. This will also depend on the SQL Variant that you are using.
If several developers are working on one Django codebase it might lead to a merging of database migrations. This can cause a friction in the development process of the team requiring migrations to be manually linearized.
Django is certainly a robust framework full of features for your backend services but there are a few let down to watch for. Implementing good code organization in Django apps will prove beneficial avoiding refactoring work. If features like GFK and ORM are used suitably to control your database you can be sure to migrate to new technologies in the future.