Get client feedback on your Django application

Q: Should I use manage.py runserver for client review?

Not as a production review environment. Django describes runserver as a lightweight development server that is not suitable for production. Deploy through a production WSGI or ASGI server instead.

Q: Can I review both WSGI and ASGI deployments?

Yes. Django supports both deployment interfaces. BugSmash reviews the accessible browser URL produced by the deployment you choose.

Q: Why must DEBUG be false?

Django warns that DEBUG pages expose detailed application data, including source code, local variables, settings, and other sensitive information. Use production-safe settings for external review.

Q: Why are styles or scripts missing from the review site?

The production deployment may not have the current static assets. Django's deployment workflow collects them into STATIC_ROOT with collectstatic so they can be served by the production web server or CDN.

Q: What does ALLOWED_HOSTS change?

When DEBUG is false, Django requires ALLOWED_HOSTS to include the hostnames the application may serve. Add the actual review domain to the production or staging configuration.

Q: Can reviewers test a signed-in Django application?

A standard login flow can be reviewed with a permitted test account. For SSO-only or long-lived stateful sessions, use the BugSmash Feedback Widget inside the application.

Q: Do reviewers need server or repository access?

No. They review the deployed browser interface rather than the Python project, administration shell, or hosting dashboard.

Paste a browser-accessible Django deployment, send one review link, and collect comments on the pages and application states your users will actually see. Every note keeps its URL, browser, device and screenshot context.

See how it works

Loved by1,250+Agenciesand companies in 100+ countries

Django runs the application. Review the deployed browser experience.

Django supports both WSGI and ASGI deployment. Its official deployment guidance separates the development server from production serving and calls out settings, static files, HTTPS, and error reporting as production concerns.

Those deployment choices determine what a reviewer can open. Four boundaries matter:

runserver is not a production server.
Django describes manage.py runserver as a lightweight development server and says it is not suitable for production. Use a production WSGI or ASGI server for a durable review environment.
Production settings control whether the site opens safely.
Django requires an appropriate ALLOWED_HOSTS value when DEBUG is false and warns that DEBUG output can expose source code, local variables, settings, and other sensitive information.
Static files need a production publishing step.
Django's deployment guidance uses STATIC_ROOT and collectstatic to gather production static assets. Run that process whenever reviewed CSS, JavaScript, or images change.
Authentication and data shape the visible application.
Reviewers can only inspect pages their account and the deployed test data let them reach. Prepare permitted accounts and representative records for sign-off.

BugSmash adds the review layer around the Django deployment:

review accessible pages in a real browser, keep comments attached to the rendered URL and element, and preserve approval outside the framework and hosting environment.

How it works

Three steps to a reviewed Django application

Deploy the release configuration

Publish the Django application through its production WSGI or ASGI stack, collect its static files, and confirm every URL included in review is accessible.

Send one review link

Paste the deployed URL into BugSmash and share the generated link. Reviewers comment on the rendered application without needing source-code or server access.

Resolve feedback with its context

Each item carries the page URL, selected element, screenshot, browser and device. Assign it, update its status, or send it into the team's delivery tools.

Review the deployed Django experience, route by route

Comment on rendered pages

Attach feedback to the visible interface and URL instead of translating it into view, template, or URLconf terminology.

Review responsive layouts

Check desktop, tablet and mobile states from one link and keep the viewport with every comment.

Capture browser context

Browser, device, screenshot and page URL arrive with every report.

Cover authenticated workflows

Use permitted test accounts and representative data so reviewers can reach the forms, dashboards, validation states, and permissions that need approval.

Validate published static assets

Review the CSS, JavaScript and images served from the deployment after collectstatic has prepared the current release.

Keep release approval

Preserve the review record independently of later template, Python, static-file, data, or server changes.

Will it work on my Django application?

BugSmash reviews a browser-accessible Django frontend. The WSGI or ASGI deployment, settings, static-file serving, authentication, and permissions still determine what the reviewer can open.

Your URL	Review by URL	What to do
Public production WSGI deployment	Works	Paste the public URL and start the review.
Public production ASGI deployment	Works	Use the deployed URL after confirming the ASGI server and application are configured for production.
Accessible Django staging environment	Works	Use the staging URL after checking its host settings, static assets, permissions, and test data.
Deployment missing current static files	Fix before review	Run collectstatic and publish the resulting STATIC_ROOT through the deployment's static-file server or CDN.
Local manage.py runserver	Not directly	Deploy the application or expose the local environment through a secure HTTPS tunnel.
Application behind login or SSO	Access-dependent	Use a permitted test account for a standard login flow, or install the BugSmash Feedback Widget for stateful or SSO-only sessions.

Using the BugSmash Feedback Widget in a Django application

Add the BugSmash script to the browser-facing Django interface when reviewers must remain inside authenticated or stateful flows. Install it in the base template or frontend shell used by the pages under review.