# hartlingowners — brief

> Project genesis. What this project is, who it's for, why it exists.

## What
One codebase — a private **condo-owner document portal** — deployed as **three
independent instances** for three Hartling Group strata properties:

- **The Sands** — thesandsowners.com (staging: hartling-thesandsowners)
- **The Shore Club** — shoreclubowners.com (staging: hartling-shoreclubowners)
- **The Palms** — thepalmsowners.com (staging: hartling-thepalmsowners)

Replaces three ageing WordPress sites. Each instance has its own domain,
branding, users, and documents; features are developed once in the shared
codebase. Same feature set, per-property data isolation.

## Who
- Owner / developer: rian
- Client contact: Joan Hagan (Director of Owner Relations, Hartling Group) +
  Karen, Dawn (staff who manage owners/documents).
- End users: condo owners who log in to read documents and see the board.

## Why
Client asked for a rebuild (email thread in `notes/`, approved scope 2026-08-13,
$7,000 for all 3). The document library is disorganized and the sites are poor
on mobile. Overarching goals:
1. **A far better, easier document library** (the only part owners really use).
2. **Airtight document protection** — a prior WP site leaked an owner's private
   file into Google's index; financials were equally exposed. This must never
   recur. See `.memory/`.
3. **Self-service for staff** — make uploading docs and creating/resetting
   users so easy the client stops emailing rian to do it.

## Scope (approved by client 2026-08-13)
Document library (improved) · document protection · user management + login
activity view · self-service password reset · board-member pages · mobile
responsive · light design refresh · admin-only owner directory (NOT owner-facing).
**Explicitly cut:** forum, gallery, media clippings, most newsletters, per-owner
unit numbers. Full detail: `.logs/planning/rebuild-plan.md`.

## Domain
- Dev: <https://hartlingowners.demoing.info> (id-auth gated) — the shared dev
  workspace. (Production is NOT on this server — see Stack.)
- Live: three isolated instances on **DigitalOcean**
  (thesandsowners.com / shoreclubowners.com / thepalmsowners.com). The current
  WordPress sites (on Cloudways) are the migration SOURCE, not the new home.

## Stack — DECIDED (new stack; deviates from the v8 default — see plan §2)
**Django (Python), server-rendered, + Postgres**, deployed as **three isolated
instances from one codebase** on **DigitalOcean** (not this server; not Cloudways).
Chosen over both Laravel (rejected on unfamiliarity) and the v8 FastAPI+React house
stack because this app is auth/admin-heavy but UI-light: Django's built-in admin,
session auth, password reset, and pluggable hasher chain (the clean seam for
verifying owners' legacy WordPress hashes and upgrading them on login) turn the
repeating parts into framework infrastructure instead of code we own forever. Fleet
consistency lives at the ops layer (Postgres, Docker, the v8 workspace, coding.md),
which Django keeps. NEW stack for the standards library: a `django.md` dispatch doc
("auth/admin-heavy, UI-light portal -> Django; interactive app-like product ->
FastAPI+React") is a plan deliverable, and it must also fill the react.md/coding.md
gap that "identity comes from the id-auth gate" leaves for ungated client apps.
Decision reached jointly with the `professormediagroup` session. Full reasoning in
the plan.

## Related projects
Sibling Hartling projects under `/srv/apps/`: `hartlinggroup`,
`hartling-email-lists`, and the three `hartling-*owners` **staging copies this
project replaces**. The `hartling-*owners` dirs are the WordPress sources to
migrate FROM; this workspace is the new build.

## Not doing
- Not rebuilding in WordPress. Not hosting production on Cloudways or on this
  server — production is DigitalOcean.
- Not Laravel, and not the v8 BW/id-auth app standard (see Stack).
- No forum, no gallery, no owner-facing directory, no per-owner unit numbers.