page:blueprints:property management:vendor portal:laravel

Property management: vendor portal using Laravel

Summary

A vendor portal blueprint for property management built with Laravel 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;
• document_access (document_id, principal_reference, role, granted_at): who may read which document. 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 Laravel: 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).

Resource Requirements

• primitive:compute
• primitive:postgres
• primitive:s3-compatible-object-storage

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.
• S3-compatible object storage: Buckets are S3-compatible with issued credentials; PutObject and GetObject are verified by canary. Other S3 operations are not verified.

Workflow Steps

1. Model the property management domain: Create the tables listings, agencies, maintenance_vendors, reports, document_access. Rental listings with publishing status live 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 vendors scoped to the agency with roles.
3. Workflow step 2: Authorize document access by vendor and role (401, 403 negative tests).
4. Workflow step 3: Store vendor documents in the private bucket.
5. Workflow step 4: Deploy and verify the negative tests and an authorized download.
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/private-document-library) and your own acceptance checks for the property management workflow.

Limitations

• The technical basis (private document library on Laravel) 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.
• Public content and synthetic examples only until actual data-handling requirements have been reviewed.

Next Actions

• Browse the catalog index: GET /v1/catalog
• Search published recipes by intent, stack and constraints: POST /v1/catalog/search
• Prepare a side-effect-free deployment plan for an authorized project: POST /v1/catalog/plan
• Read the existing agent authentication setup: GET /mcp/setup
• Browse Property management: GET /v1/catalog/nodes/industry%3Aproperty-management
• Browse Vendor portal: GET /v1/catalog/nodes/workload%3Avendor-portal
• Browse Laravel: GET /v1/catalog/nodes/stack%3Aframework-laravel
• Browse Deploy web app: GET /v1/catalog/nodes/intent%3Adeploy-web-app

Examples

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