Architecture practices: client portal using Django

Overview

A client portal blueprint for architecture practices built with Django on Ample. Domain schema:

• client_entities (name, entity_type, site_address): clients and project sites;
• projects (client_entity_id, project_name, stage, period_start, period_end): engagement periods by RIBA/AIA-style stage;
• drawing_sets (project_id, set_name, revision, object_key, issued_at): versioned drawing issues;
• approvals (project_id, drawing_set_id, approver_role, decided_at, decision): client sign-offs per issue;
• document_access (document_id, principal_reference, role, granted_at): who may read which document.

Public information includes portfolio and services, team and accreditations, and studio locations. Sensitive information kept out of scope until further handling: unreleased drawings and site surveys, planning submissions before filing, client contact details. Drawings and surveys are client-confidential until issued; the portal models per-project authorization only.

Technical Basis

Verified on Django: a role-to-document access model with negative tests (401 without identity, 403 for the wrong role) and a private-bucket round-trip for the allowed role (private=ok).

Queries

• Architecture practices: client portal using Django
• Where can I host Architecture practices: Client portal built with Django?
• I need a genuinely specialized client portal workflow covering project phases, drawing versions and reviewer access.

Resource Requirements

• Compute
• Postgres
• S3-compatible object storage

Infrastructure Requirements

1. Compute: Auto-pause when idle.
2. Postgres: Managed PostgreSQL 16, auto-provisioned.
3. S3-compatible object storage: Verified by canary.

Framework

Django

Workload

Client portal

Industry

Architecture practices

Release Status

Published

Support Status

Verified

Execution Status

Ready

Workflow Steps

1. Model the architecture practices domain: Create the tables client_entities, projects, drawing_sets, approvals, document_access.
2. Model client entities and engagement periods: Every document belongs to one engagement.
3. Authorize by client entity and role: 401 without identity, 403 for the wrong client.
4. Store documents in the private bucket and stream them through the app.
5. Deploy: Run the synchronous deploy once and read the result.
6. Verify: Run the pattern self-test(s) from the example.

Examples

• Django pattern fixture: Verified private document library basis for this blueprint.

Cost Estimate

• Currency: USD
• Monthly Amount: $10.00
  • Components:
    • App server: $5.00
    • Managed PostgreSQL database: $5.00

Limitations

• No health, financial, privacy, or other compliance claim is made. Drawings and surveys are client-confidential until issued.
• Public content and synthetic examples only until actual data-handling requirements have been reviewed.

Next Actions

1. Browse the catalog index
2. Search published recipes by intent, stack, and constraints
3. Prepare a side-effect-free deployment plan for an authorized project