BadHOA.com — Rebuilding an HOA-Accountability Platform on a Clean, Compliance-Aware Schema

BadHOA.com

A full rebuild of an Arizona HOA-accountability platform: a clean restricted-access schema, an ingestion pipeline mirroring state corporation, parcel, and recorded-document records, and passkey-based member registration.

  • PHP
  • MySQL
  • WebAuthn / Passkeys
  • OIDC
  • ETL
  • RBAC

Problem

The original platform had grown organically until its data model and its access rules were tangled together — public reference material, member accounts, and sensitive owner records all shared the same tables and the same trust boundary. That made two things hard at once: adding features without risking a data-exposure mistake, and reasoning about who could see what. The project needed a rebuild that treated access control as a schema-level concern rather than an afterthought in application code.

Architecture

The rebuild started from a new, purpose-built database with clear separation between public reference data, authenticated-member data, and restricted records. On top of it sits an ingestion pipeline that mirrors public-record sources on a schedule: state corporation-commission entity records (associations, their directors, and statutory agents), county parcel and ownership data, and recorded governing documents. Each source is normalized into its own set of tables with stable keys so re-runs are idempotent rather than duplicative.

Member registration was rebuilt on WebAuthn / passkeys with an OIDC path, so authentication does not depend on shared secrets sitting in the database. A role-based access layer (groups → roles → permissions) gates both the member area and an admin console, and the same permission checks the UI uses are enforced server-side before any restricted record is read.

Outcome

The platform now runs on a schema where the trust boundary is explicit: public pages never touch restricted tables, and the ingestion jobs refresh entity, parcel, and document data without manual re-keying. Registration is phishing-resistant by default, and new features can be added against a data model that says, structurally, what is public and what is not.


Start a project like this All case studies