An HOA management company moved violations, dues, and work orders into a homeowner portal

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

Forty homeowner associations across the region rely on this management company for dues collection, architectural requests, violation handling, and common-area maintenance. Each community has a board with its own rules, dues schedule, and tolerance for deviation, and the company's community managers are the interface between homeowners, boards, and contractors. Board meetings run monthly; violation disputes and dues questions arrive daily. Before the portal, every one of those interactions was a phone call or an envelope, and each manager kept the record in whichever format their community's history had accumulated.

What it was costing

Homeowners phoned or mailed everything — dues questions, violation appeals, common-area repair requests — and community managers spent their days as transcriptionists between homeowners, boards, and contractors.

What they could see

• Managers spent their days transcribing: homeowner phone calls became emails to boards, board replies became letters back.
• Violation disputes escalated to board meetings because homeowners and managers disagreed about what had been sent and when.
• Dues questions required pulling a ledger, a payment record, and the community's schedule from three places.
• Work orders for common-area repairs lived in contractors' inboxes; managers chased status by phone between board meetings.
• Onboarding a new community meant weeks of manual setup because every rule lived in a past board's documents.

The constraints we worked inside

• Each community's board sets its own rules and dues schedules; the portal must be configurable per community without code.
• Violation workflows are quasi-legal — notices, appeal windows, and records must follow each community's stated process exactly.
• Some homeowners will never use a portal; mail and phone channels must keep working untouched.

What had been tried before

Deployed a generic HOA portal product across three communities as a trial.

Its fixed violation workflow matched none of the boards' actual processes, and the vendor priced per-community configuration as custom work at custom rates.

Built shared inboxes and a ticketing spreadsheet so managers could route homeowner requests.

Requests arrived by phone and paper regardless, and the routing added a step without removing transcription — managers still retyped everything either way.

Hired seasonal office help each summer to absorb call volume during violation season.

Seasonal staff could answer phones but not interpret each community's rules, so escalations reached boards anyway and cost repeated re-training every year.

What we proposed

We proposed a homeowner portal whose unit of configuration is the community, not the codebase: rules, dues schedules, and violation workflows are data per community, so adding one is reviewed configuration rather than a development ticket. The paper trail is the feature — every notice, appeal, and work order becomes a timestamped record both manager and homeowner can see, which is where quasi-legal disputes end. Mail and phone stay first-class: printed notices and phone intake land in the same system the portal writes to, so the company gains a channel for connected homeowners without abandoning the neighbors who will never log in.

Just as important is what we ruled out, and why:

• Configuring a multi-tenant HOA SaaS per community — No SaaS workflow could express some boards' appeal processes, and per-community configuration was priced as recurring custom work — the wrong cost shape for boards that amend rules yearly.
• A single standardized workflow all communities must adopt — Boards set their own rules by statute and temperament; forcing one workflow would stall at the first board that refused, and most communities is not a rollout.
• Phone-tree automation to deflect inbound calls — Deflection without a record just moves the argument; the company's actual problem was disputed facts, and a phone tree produces none.

How the work ran

Delivered by the systems pod — 2 engineers over 12 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

Next.js

Homeowners, managers, and board members share one portal, and server rendering keeps it usable for members who log in twice a year from whatever device they own.

TypeScript

Violation workflows are quasi-legal state machines; typed states and transitions make an illegal sequence — a notice before its required warning — a compile error, not a lawsuit.

Postgres

Disputes end at the record, so every notice and appeal needs a trustworthy timestamped history — append-friendly relational tables with row-level audit give exactly that.

Per-community config layer

Each board's rules become reviewed data instead of a branch; onboarding a community is a checklist a manager completes, not a sprint the company schedules.

Role-based access

Homeowner, board member, manager, and contractor see different truths of the same record; role boundaries also keep one community's data invisible to another's board.

What went wrong

How we worked together

Cadence

Weekly Thursday demos recorded for managers who were in the field, plus a written decision log; two board representatives joined milestone reviews per community wave.

Client side

A director of community operations owned the rollout, one senior manager per pilot wave supplied the process truth, and the owner arbitrated board friction.

Decisions

Where two communities' processes conflicted, the stricter record-keeping won; anything touching quasi-legal notices was checked against each community's own documents before build.

They provided

Each pilot community's governing documents and dues schedules, manager time for workflow interviews, and access to the mailing vendor's process.

What changed

The headline: homeowner requests and payments flowing through the portal in the first wave of communities — Phone-and-mail → portal with receipts, read from Manager time log. A second check: violation-dispute escalations to board meetings at −44%.

Managers describe a different working day: requests arrive with records attached instead of as stories to be written down, and disputes end at the timestamp rather than at whoever remembers loudest. Boards receive clean packets — notices, appeals, work orders in sequence — instead of reconstructed histories, and the quasi-legal edge of violation handling stopped being scary because the process is now the document. Offline neighbors still call and get letters, but those interactions land in the same timeline, so a manager never maintains two versions of one community's truth.

The result was read from Manager time log against the pre-engagement baseline over the stated window, with a guardrail check on violation-dispute escalations to board meetings. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• The portal repository with per-community configuration documentation and test suite
• The community-onboarding checklist managers use to configure a new association
• Role and access administration guide for managers, boards, and contractors
• Printed-notice and mail-intake templates aligned with the record model