Exercise 3: Why Deployment Reveals runserver's and SQLite's Real Limits — Possible Solution
====================================================================

WHY BOTH WERE GENUINELY APPROPRIATE EARLIER
------------------------------
Chapter 1 used manage.py runserver because it's exactly the right tool for local development - quick to start, no separate configuration needed. Chapter 2 chose SQLite as a genuinely appropriate choice, not a placeholder, because it fits a single-developer, low-concurrency development workflow perfectly well, with zero setup required beyond what Django already provides by default.

WHY DEPLOYMENT IS WHERE THEIR REAL LIMITS SHOW UP
------------------------------
Django's own documentation is explicit that runserver was never built for production use - it lacks the concurrency handling and security hardening a real WSGI server like gunicorn provides, a limitation that's invisible during single-developer local testing but becomes a real problem the moment actual production traffic needs to be served reliably. SQLite's own limitation is different: its file-level locking becomes a genuine concurrency bottleneck specifically under real multi-user, high-write-volume load - a condition that simply doesn't arise during solo development, but can become a genuine constraint once a deployment serves many simultaneous real users.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains that both tools were the right choice for the development conditions they were used under, and correctly identifies that deployment introduces genuinely different conditions (real concurrent production traffic) that expose limitations - runserver's lack of production hardening and SQLite's file-locking bottleneck - that never mattered during earlier, single-developer use.