Common Mistakes & Warnings¶
This section documents real-world failure points that usually appear after purchase , when someone starts modifying the project without fully understanding its contracts.
Read this section before making your first major customization .
Granting Access Without PurchasedProduct (Critical)¶
The Mistake¶
Developers try to:
- mark an order as paid
- allow downloads based on
Order.is_paid - or bypass access checks for testing
Why This Is Dangerous¶
- Breaks lifetime-access guarantee
- Breaks refunds
- Breaks support eligibility
- Creates invisible security holes
Correct Rule¶
Access exists if and only if
PurchasedProductexists.
If you remember only one rule from this documentation, remember this one.
Creating Circular Dependencies Between Apps¶
The Mistake¶
- Importing seller logic into payments
- Importing support logic into core
- Letting UI apps write business state
Why This Happens¶
- “It was easier here”
- “Just one small change”
Why This Is Dangerous¶
- Tight coupling
- Untraceable bugs
- Impossible refactors later
Correct Pattern¶
- Business flows forward
- UI reads, orchestrates, but never owns
Using Generic Views Directly¶
The Mistake¶
Using:
GenericUserProfileView
directly in urls.py
Why This Breaks¶
form_classis not defined- Templates assume role context
- Crashes at runtime
Correct Usage¶
Generic views must always be subclassed by:
customerseller
They are contracts , not endpoints.
Editing Signals Without Understanding Side Effects¶
The Mistake¶
- Removing Dodo signals
- Modifying product sync logic
- Adding business logic inside signals
Why This Is Dangerous¶
- Signals are implicit
- Fire on save/delete
- Can silently break payment sync
Rule¶
Signals may sync, mirror, or notify —
they must never decide business truth.
Making Support Independent of Purchases¶
The Mistake¶
- Allowing support without ownership
- Removing PurchasedProduct dependency
- Creating “manual” support entries
Consequences¶
- Unlimited unpaid support
- No customer-product traceability
- Seller workload explosion
Correct Model¶
Support is:
- optional
- repeatable
- always paid or controlled
Modifying Webhook Logic Casually¶
The Mistake¶
- Logging instead of enforcing atomicity
- Updating Order but skipping PurchasedProduct
- Ignoring duplicate webhook calls
Why This Is Critical¶
Webhooks are:
- asynchronous
- retried
- out of your control
Correct Principles¶
- Always idempotent
- Always atomic
- Always validate payload
Removing Caching “Because It Works Without It”¶
The Mistake¶
- Removing cache from short URLs
- Removing under-construction cache
- Removing analytics caching
Why This Is Dangerous¶
- Sudden performance collapse
- Increased DB load
- Worse user experience under traffic
Correct Rule¶
Cache is a performance contract, not an optimization luxury.
Hardcoding Environment-Specific Behavior¶
The Mistake¶
- Assuming local storage paths
- Hardcoding S3 URLs
- Writing logic that works only in DEBUG
Why This Breaks Production¶
- Local ≠ Production
- Storage and URLs differ
- Security assumptions break
Correct Pattern¶
- Use settings
- Use abstractions
- Respect environment switches
Adding “Quick Fixes” in UI Apps¶
The Mistake¶
- Granting access in templates
- Writing business logic in views
- Skipping validation for speed
Long-Term Impact¶
- Hidden bugs
- Inconsistent behavior
- Impossible debugging
Correct Rule¶
UI apps never decide truth .
They only display it.
Ignoring Admin as a First-Class Interface¶
The Mistake¶
- Treating Django admin as secondary
- Bypassing admin workflows
- Not syncing admin actions with business rules
Why This Matters¶
Admin is:
- your emergency control panel
- your audit surface
- your safety net
Breaking admin consistency breaks recovery.
Final Architectural Warning¶
This system is:
- modular
- extensible
- production-ready
But only if you:
- respect ownership
- follow the contracts
- extend, not override
Most bugs in this system will not come from missing code,
but from breaking invisible rules.