Create a Demo Mode for your App - EASY

▶

I'm going to show you the steps I follow to create a demo mode in an app. This is useful if you want to present your project to an end user, whether a client or anyone else interested.

Create a demo mode of any project

The structure I'm about to explain can be applied to any technology.
In this case, I'm using Laravel, but the same would work in other environments.

The important thing here is to define some custom environment variables:

• This can be easily done in Python, Node, or PHP.
• Even in Flutter, it can be managed with constants.
• APP_DEMO environment variable

.env

APP_DEMO=true

Create a variable called APP_DEMO, which indicates whether the application is in demo mode or not.

What is the purpose of a demo mode?

I think the idea is clear: when you have your project and want to present it to an end user.
In my case, that end user is you. In the video description, I've provided links to demo applications I'm uploading for you to check out.

In your case, it could be, for example, an online store you want to show to a client. Instead of sending them images or posts, you give them access to a real demo where they can try out the application personally.

If it's public, as in my case, it's necessary to lock certain operations to prevent them from deleting records or modifying things that aren't appropriate.

What's the difference between a regular app and a demo app?

Basically that in the demo:

• Certain operations, such as creating, deleting, or modifying, are blocked.
• This prevents anyone from uploading inappropriate or unauthorized information.
• In my case, I also block user registration and access to the authenticated dashboard, leaving only test data available.
• Use of the variable throughout the app

I apply the APP_DEMO variable to several parts of the application; for example:

function delete(Category $category)
{
    session()->flash('status', __("Delete successfully."));
    if (!env('APP_DEMO'))
        $category->delete();
    return $this->redirect(url()->previous());
}

Example: 

• In a controller, I prevent an upload from being made.
• In the case of payments, I simply return a simulated payment.
• This way, I block sensitive transactions without affecting the rest of the flow.

When the app is not in demo mode, the system operates normally.

In demo mode, I also took the opportunity to display additional information, such as the authenticated user's details:

layouts/master.blade.php

    @if (env('APP_DEMO'))
        @guest
            <div class=" max-w-96 m-4">
                <div class="mycard mx-auto">
                    <ul>
                        <li>User Test: </li>
                        <li>User: user@user.net</li>
                        <li>Password: password</li>
                    </ul>
                </div>
            </div>
        @endguest
        @auth
            <div class=" max-w-96 m-4">
                <div class="mycard mx-auto">
                    <ul>
                        <li><a href="/dashboard/category">Dashboard</a></li>
                    </ul>
                </div>
            </div>
        @endauth
    @endif

For example, on the dashboard, even if you try to modify data, the changes won't be saved due to the restriction.

If I exit demo mode, the app returns to normal operation.

Why environment variable and not configuration?

I decided to use an environment variable instead of a setting. The advantage is that:

• If not defined, the system continues to operate normally.
• If defined, it automatically activates demo mode.
• This is convenient and avoids extra complications.

Middleware as an alternative

In Laravel, you could also create middleware to directly block all POST or PUT operations.

The caveat is that in some cases, Laravel handles internal processes that don't work directly with these methods, so I preferred to do it manually at each step.

Still, it would be a cleaner option in certain scenarios.

Conclusion

The demo mode is essentially a block of critical operations while allowing the main functionalities of the application to be showcased.

With a few steps, we can create a demo mode in Django:

1. Configuration/environment variable.
2. Block sensitive operations.
3. Display demo user information.

This way, you can present your project without running the risk of someone modifying real data.

DEMO Mode in Django

▶

First step: Configuration

Everything begins by creating an environment or configuration variable.
In Django, unlike other frameworks like Flask or FastAPI, we don't always have a default environment file, but we can configure it easily.

The important thing is to have a variable that we can consult throughout the entire project.

settings.py

DEMO = True

Second step: blocking operations

Depending on the purpose of your demo, you will have to block some operations:

• Create
• Update
• Delete

An elegant way to do this is by using middleware, which intercepts POST or PUT requests. For example, letting the login pass but blocking the rest.

In my case, I have also managed it with conditionals that check if we are in demo mode, and if so, prevent any modifications.

For example, in Django Admin, we can configure something like:

admin.py

from django.contrib import admin

from django.contrib import messages

from .models import Element, Category, Type

# Register your models here.


from django.conf import settings


if settings.DEMO:
    class ReadOnlyAdmin(admin.ModelAdmin):
        """
        Admin que permite navegar, abrir formularios y mostrar botones,
        pero NO guarda, crea ni elimina nada en la base de datos.
        """
        def save_model(self, request, obj, form, change):
            messages.warning(
                request,
                "Este modelo es de solo lectura. Los cambios no se guardaron."
            )

        def delete_model(self, request, obj):
            messages.warning(
                request,
                "Este modelo es de solo lectura. La eliminación no se realizó."
            )

        def delete_queryset(self, request, queryset):
            messages.warning(
                request,
                "Este modelo es de solo lectura. No se eliminaron registros."
            )
    admin.site.register(Element, ReadOnlyAdmin)
    admin.site.register(Category, ReadOnlyAdmin)
    admin.site.register(Type, ReadOnlyAdmin)
else:
    admin.site.register(Element)
    admin.site.register(Category)
    admin.site.register(Type)

Third step: presenting information to the user

Another important part is showing demo user information:

• Access to an authenticated user.
• Allow test purchases.
• Display dashboards or panels with sample data.

In the case of Django Admin, I don't see it as necessary, since normal users cannot enter the panel by default, but in a more customizable project (like a store), it is recommended.

Implementation in Django

In Django, we can manage the demo mode in two layers:

In the view (controllers):

• We consult the environment/configuration variable and block operations as appropriate.

In the templates:

• Here we have two options:
• Create a custom tag.
• Use a context processor to define global variables.

Custom tag

We create a tag in the project, register the configuration and return a boolean value.
In the template, we cast that value into a variable (is_demo) and use conditionals to show or hide information blocks:

<APP>/templatetags/modo_demo.py

from django import template
from django.conf import settings

register = template.Library()

@register.simple_tag
def is_demo():
    """
    Verifica el valor de DEMO en settings y lo retorna.
    Devuelve False por defecto si no se encuentra.
    """

    return getattr(settings, 'DEMO', False)

In the template we load the tag:

{% load modo_demo %}
{% demo as is_demo %}
{% if is_demo %}
  <div>
      User demo: demo / demo123  
      <a href="{% url 'login' %}">Iniciar sesión</a>
  </div>
{% endif %}