Equipment rental: Inventory manager using Django

Summary

A inventory manager blueprint for equipment rental built with Django on Ample.

Domain schema:

• equipment (sku, name, category, day_rate, serial_tracked): rental catalog;
• stock_movements (sku, unit_serial, delta, reason, moved_at): check-outs, returns and maintenance;
• rentals (rental_no, period_start, period_end, status): rentals with status transitions;
• rental_lines (rental_no, sku, unit_serial, rate): rental contents;
• events (seq, record_type, record_id, kind, at): application-owned history written in the same transaction.

Public information: equipment catalog and rates, availability calendar, deposit and insurance terms. Kept out of scope until handling is reviewed: renter identity documents, payment and deposit details. Identity verification and deposits are outside these flows; only availability and rental status are modeled.

Technical basis verified on Django: an optimistic version check and an event row written in the same transaction, a stale update rejected, and a history query over the application-owned events (history=2 conflict=rejected).

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
• A review of which equipment rental data classes may be handled at all; this blueprint models public information only

Framework and Resource Requirements

• Framework: Django
• Workload: Inventory manager
• Industry: Equipment rental
• Resource Requirements:
  • primitive:compute
  • primitive:postgres
  • primitive:s3-compatible-object-storage

Workflow Steps

1. Model the equipment rental domain: Create the tables equipment, stock_movements, rentals, rental_lines, events. Rental catalog lives in equipment; keep the sensitive classes (renter identity documents, payment and deposit details) out of this schema.
2. Workflow step 1: Model SKUs and stock movements; derive stock from movements
3. Workflow step 2: Apply movements transactionally with an optimistic version check on the SKU
4. Workflow step 3: Record an event per movement for history
5. Workflow step 4: Deploy and verify history and rejected stale updates
6. Deploy: Run the synchronous deploy once and read the result. Re-running with no change is a no-op.

Examples

• Title: Django pattern fixture
  Description: Verified transactional workflows basis for this blueprint.
  Source Ref: tests/deploy-canaries/django-patterns

Success Checks

• app responds on its public URL
  kind: http_get
  path: /
  expect: ample canary django patterns
• transactional-workflows self-test from the example
  kind: http_get
  path: /p/transactional-workflows
  expect: see the pattern fixture checks

Limitations

• The technical basis (transactional workflows on Django) was verified with the pattern fixture; the equipment rental 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. Identity verification and deposits are outside these flows; only availability and rental status 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) at build revision 1ac5595375130d45290090e82ed0f554ccd45405-dirty
• Components:
  • app server: size s-1vcpu-1gb, quantity 1.0, monthly amount 5.0
  • managed PostgreSQL database: size s-1vcpu-1gb, quantity 1.0, monthly amount 5.0

Note: Always-on monthly price of the tested sizes; apps and databases auto-pause when idle. Buckets are allocation-priced per quota and not included.