Improve beginner experience on free tier

While working with PythonAnywhere during the Djangonaut Space program, I identified several constraints in the free tier that can introduce friction for first-time Django deployments.

The primary issue is not the limitations themselves, but that they are often only discovered at runtime, making it difficult for users to distinguish between platform constraints and application-level misconfiguration.

## Deployment Issues Identified
# 1. Custom domains are not supported

Many deployment guides assume the ability to configure a custom domain (e.g. myapp.com) via DNS. On the free tier, applications are restricted to the default *.pythonanywhere.com subdomain.

Impact:
Users may attempt DNS configuration and interpret the failure as incorrect DNS records, SSL misconfiguration, or application routing issues, rather than a platform limitation.

# 2. Restricted outbound network access

Applications that depend on outbound HTTP requests (e.g. third-party APIs) may fail or behave inconsistently due to network restrictions on the free tier.

Impact:
From the application perspective, these failures can resemble standard runtime errors (timeouts, connection errors), making it non-obvious that the root cause is environment-level network policy rather than application logic.

# 3. No support for persistent background workers

Free tier environments do not support always-on processes (e.g. Celery workers, long-running jobs, or persistent task queues).

Impact:
Functionality that depends on asynchronous or background execution may not run as expected after deployment, even if it works correctly in a local development environment. Failures are often silent or indirect, making diagnosis difficult for new users.

## Proposed Direction (Tooling Integration)

As part of my work with Django Simple Deploy, I’ve been exploring a mechanism to surface these constraints earlier in the deployment process.

The idea is to introduce a `--free-tier` flag that:

- Detects or assumes a constrained hosting environment
- Performs pre-deployment checks against known platform limitations
- Emits warnings for unsupported or restricted features

Example warnings:

- “Custom domain configuration is not supported on the free tier; default subdomain will be used.”
- “Outbound network access may be restricted; external API calls could fail at runtime.”
- “Persistent background workers are not available; asynchronous tasks may not execute.”

This approach helps catch potential issues before deployment instead of at runtime, making things clearer and easier to debug, especially for beginners. I’d be interested to hear your thoughts on this.