This is how neighbors.fyi works for residents.
Start a free community for your HOA
Admin·6 min read·Updated July 25, 2026

Site settings

The system_admin-only knob room. branding, plan + billing, account owner, custom domain, integrations, and feature toggles. the day-to-day category and color settings live on the separate Setup page.

On this page

Who can open it

Site Settings requires the system_admin role. A plain admin doesn’t see the link on the admin panel and is redirected to /admin if they hit the URL directly. The intent is to keep platform-level changes (theme, plan, custom domain, feature toggles) on a small blast radius. one or two people per community.

Page layout

On wide screens the page is two columns: the App Config card is on the left and sticks to the viewport, the rest of the sections stack on the right and scroll independently. On narrow screens everything stacks linearly. Each section on the right is a self-contained accordion with its own save button. nothing here is a single global save.

The sections, grouped

Identity & theme. App name, theme preset, custom brand color, surface color, active modes (community / demo). Changes are visible everywhere the app reads app_config on next render.

Plan & billing. Current tier, household count basis, link out to manage subscription on the admin portal. Custom domain (e.g. portal.your-hoa.com) is configured here too. you get DNS records to set on your registrar after saving.

Integrations. Google Meet OAuth (connect an account so admins can generate meet links from event forms) and Stripe-backed payment settings (the toggle between an external payment URL and integrated Stripe, who covers the processing fee, and the payment note shown to residents on the pay screen).

Feature management. Per-page on/off toggles for ~23 resident-facing surfaces. Disabling a feature hides its nav item and redirects its URL to /dashboard. Items locked by community-mode display a lock until the mode is cleared.

Category & color settings live on the Setup page
The taxonomy admins edit day to day. community-issue / architectural / document / vendor / violation categories, calendar event types, chat sidebar groups, and the topic + banner color palettes. moved to the separate Setup page (/admin/setup) in the Phase 43.m split, which any full admin (admin or system_admin) can open. a scoped module-admin cannot. Site Settings keeps only the platform-level knobs above. See the Setup tutorial for those.

Who pays the card fee

The Payment Settings card holds the one setting on this page that changes what your residents are charged, so it is worth understanding before you touch it. It only appears once the community is on integrated Stripe.

Absorb (the default). The resident pays exactly their assessment and the association nets the assessment minus Stripe’s processing fee. The fee becomes a budget line item, the same way it would with any merchant account.

Pass-through. A service fee is added at checkout, shown to the resident in dollars before they pay. The resident picks bank or card first, and bank always carries the lower fee.

Pass-through does not make the association money
The fee is grossed up, meaning it is calculated so the association nets the assessment to the cent. Expected margin is zero, not positive. If you are choosing pass-through hoping to come out ahead, it will not do that. what it does is move the processing cost off your budget and onto the residents who choose to pay by card.

Debit cards never carry the fee. Card network rules prohibit surcharging debit, so a resident paying by debit pays the assessment exactly and the association absorbs that (smaller) cost. You will still have some processing cost under pass-through, and that is expected.

Leave bank payment on
Bank/ACH is always available and that is deliberate: a genuine no-fee way to pay is what makes charging the fee defensible in the first place. Turning cards off is a normal, supported choice. trying to force everyone onto cards is not, and it undercuts the basis for the fee. Our counsel cleared pass-through on the condition that the debit waiver and the bank option both stay in place.

Rates are set by Stripe’s agreement with your association, not by us. Every payment is a direct charge on your own Stripe account, so your rate is whatever you have with Stripe. see stripe.com/pricing. Bank payments cost the association substantially less to process than cards, which is the usual reason a board restricts card payments.

Switching modes is audit-logged, and turning cards off never cancels an existing auto-pay. see Dues & payments for what residents experience.

Account Owner & handover

One system_admin is the community’s Account Owner. the person responsible for the neighbors.fyi subscription and the payment method on file. It’s set automatically to whoever first sets up the community, and it’s shown in the Account Owner section on this page (right below Plan & billing).

Transferring ownership. If you’re the Account Owner and want to hand the community to someone else (a new board treasurer, say), pick them from the member list and send the transfer. They’re made a system_admin and asked to add their own payment method, then accept. On accepting, the subscription is repointed to their card and the previous owner’s card is removed, so ownership only moves once billing is genuinely re-homed. the community is never left without an owner, and you’re never left paying for a community you handed off.

Closing the community. If there’s genuinely no one to hand off to, the Close community option cancels the subscription at the end of the current billing period and starts the wind-down. Use this when the community is shutting the portal down, not for a routine handoff.

The Account Owner can’t just be deleted
To keep a community from being orphaned, the Account Owner can’t delete their account or be removed until ownership is transferred or the community is closed. Everyone else can leave normally.

Why some sections don’t show up

Sections whose underlying feature isn’t included on the current plan are suppressed. there’s no point letting an admin configure architectural categories if architectural review isn’t on the plan. The page reads the hidden-feature set on render; an upgrade puts the corresponding sections back the next time you load Settings.

Theme changes are global
Theme, app name, color palette, and category lists are per-community settings, not per-user. Everyone sees the change on next render. Save with intent; there’s no draft mode.

Audit trail

Every section save goes through an audited server action, so the change shows up in the audit log with the system_admin user, the field name, and the before / after values. The top of Settings has a direct link into the audit log filtered to entity_type=settings, which is the fastest way to answer “when did the theme change” or “who turned this feature off”.

Like what you’re reading?
Start a free community