Property management: public directory using Django

Summary

A public directory blueprint for property management built with Django on Ample. Domain schema:

• listings (reference, address, unit, rent, publishing_status, agency_id): rental listings with publishing status;
• agencies (name, license_number, portfolio_size): management offices;
• maintenance_vendors (name, trade, agency_id, status): vendors per office;
• reports (agency_id, period, object_key, generated_at): portfolio reports per office;
• state_transitions (record_type, from_state, to_state): the allowed state machine.

Public information: available rentals, office contacts, application process. Kept out of scope until handling is reviewed: tenant identity and payment history, inspection reports with personal data. Tenant data is personal and often regulated; only published listings and office-scoped reporting are modeled.

Technical basis verified on Django: a workspace-scoped table, an explicit state machine (draft to review to published) that rejects invalid transitions, and a cross-workspace read that returns nothing (transitions=true isolation=true).

Resource Requirements

• primitive:compute
• primitive:postgres
• primitive:cdn

Infrastructure Requirements

• Compute: Apps run in isolated x86_64 Firecracker microVMs that auto-pause when idle and wake on request; sizes are the priced VM sizes.
• Postgres: Managed PostgreSQL 16 runs in its own microVM and is auto-provisioned when an app needs a database and no DATABASE_URL is supplied.
• CDN: The CDN host serves objects from published buckets. It does not front app compute and is not a cache or key-value store.

Prerequisites

• A Django project (pip install into .ample/python from requirements.txt, then waitress serving project.wsgi from run.py reading PORT on the python-3.12 template)
• A PostgreSQL driver reading DATABASE_URL (auto-provisioned when omitted)
• Bucket credentials from ample bucket create passed as encrypted S3_* environment variables and a published bucket for public assets (CDN_*)
• A review of which property management data classes may be handled at all; this blueprint models public information only.

Workflow Steps

1. Model the property management domain: Create the tables listings, agencies, maintenance_vendors, reports, state_transitions. Rental listings with publishing status lives in listings; keep the sensitive classes (tenant identity and payment history, inspection reports with personal data) out of this schema.
2. Workflow step 1: Model listings with a publishing_status state machine scoped to the agency.
3. Workflow step 2: Serve only published listings, with media from the CDN bucket.
4. Workflow step 3: Enforce the agency scope on every query.
5. Workflow step 4: Deploy and verify a published listing and that unpublished listings are absent.
6. Deploy: Run the synchronous deploy once and read the result. Re-running with no change is a no-op.
7. Verify: Run the pattern self-test(s) from the example (/p/relational-records) and your own acceptance checks for the property management workflow.

Examples

• Django pattern fixture: Verified relational records basis for this blueprint.

Success Checks

• App responds on its public URL
• Relational-records self-test from the example

Limitations

• The technical basis (relational records on Django) was verified with the pattern fixture; the property management schema and workflow are an original design for this blueprint and were not executed as a separate application.
• No health, financial, privacy or other compliance claim is made. Tenant data is personal and often regulated; only published listings and office-scoped reporting are modeled.
• Verified on the python-3.12 template at s-1vcpu-1gb; region, request-duration limits and other sizes are unknown or unverified.

Cost Estimate

• Currency: USD
• Monthly Amount: 10.0
• Basis: size prices from pricing.toml (loaded by the API)
• Components:
  • App server: s-1vcpu-1gb - $5.00/month
  • Managed PostgreSQL database: s-1vcpu-1gb - $5.00/month

Evidence Summary

• Django pattern fixture deployed on Ample: The relational records checks passed: a workspace-scoped table, an explicit state machine (draft to review to published) that rejects invalid transitions, and a cross-workspace read that returns nothing (transitions=true isolation=true).

Next Actions

• Browse the catalog index
• Search published recipes by intent, stack and constraints
• Prepare a side-effect-free deployment plan for an authorized project
• Read the existing agent authentication setup
• Browse Property management
• Browse Public directory
• Browse Django
• Browse Deploy web app