Personal Catalogue: Django & PostgreSQL — Chapter 3, Exercise 3
====================================================

TASK
Explain why relying on the Django admin as this project's own primary
way of adding items is a reasonable choice given its real deadline,
while also explaining why it can't be the app's own final, shipped
solution.

SOLUTION

WHY IT'S REASONABLE GIVEN THE DEADLINE

The admin gives this project a complete, working, searchable, and
filterable data-entry interface for the cost of roughly fifteen lines
of admin.py code, generated automatically from the same Item, ItemType,
and Tag models already defined in Chapter 2. Building an equivalent
custom interface by hand - forms, validation, a list page, an edit
page, a delete confirmation - would take real, additional development
time this project's own deadline doesn't have room for. Choosing the
admin here isn't cutting a corner on quality; it's choosing the fastest
correct path to a genuinely working tool, with the option to build a
more tailored interface later once the schema itself is proven out
through real use.

WHY IT CAN'T BE THE FINAL, SHIPPED SOLUTION

The admin is built specifically as an internal, trusted-user management
interface, not as a public-facing product feature. Several real
limitations follow directly from that design intent: it requires a
Django auth account and login to use at all, which is the wrong
experience for a personal catalogue meant to be browsed casually; its
layout and workflow are generic, built to work reasonably for any
model rather than tailored to this project's own specific "do I
already own this?" browsing need; and exposing it in production
carelessly - at its default /admin/ URL, with weak credentials - is a
real, documented security risk, since it's a well-known target for
automated login attempts precisely because so many Django sites use
the default path unchanged.

HOW THE COURSE ACTUALLY RESOLVES THIS

The admin isn't discarded once its job is done - it stays as the
project's own genuinely useful internal management tool going forward.
Chapter 5 builds a separate, dedicated public-facing form for adding
items, and Chapter 9's own deployment coverage addresses locking the
admin down properly (a non-default URL, strong real credentials) before
the project goes anywhere near the public internet.

ANSWER: The admin is the right choice for getting a real, working
data-entry tool live quickly, since it costs almost no development time
against this project's own genuine deadline - but it's an internal
management interface by design, not a public-facing feature, and needs
both a dedicated public form (Chapter 5) and real production hardening
(Chapter 9) before the project can actually ship.

WHY THIS WORKS AS AN ANSWER
----------------------------
It grounds "reasonable for now" in a concrete time-cost comparison
rather than a vague appeal to convenience, and grounds "not the final
solution" in specific, real limitations (login requirement, generic UI,
security exposure) rather than a general sense that admin panels are
somehow lesser.