Mission & services

╔══════════════════════════════════════════════════════════════════════════════╗
║                      MISSION & SERVICES                                      ║
╚══════════════════════════════════════════════════════════════════════════════╝

Last updated : 2026-07-19 (continuity & reliance-safe language)
Audience     : Family, friends, potential customers

──────────────────────────────────────────────────────────────────────────────
OUR MISSION
──────────────────────────────────────────────────────────────────────────────

Small property operators deserve the same clarity large firms get — without
buying software built for a different species of business.

We build and operate transparent property management systems for portfolios
that need rigour, not enterprise overhead.

──────────────────────────────────────────────────────────────────────────────
WHY WE BUILT THIS
──────────────────────────────────────────────────────────────────────────────

Our family manages real properties at scale (approximately 500 doors in
Arizona, using industry-standard enterprise tools day to day).

That experience taught us what matters:

  • Rent must reconcile
  • Owner statements must be defensible
  • Work orders and expenses must trace to real units
  • Operators must understand their own numbers

It also showed us a gap: family portfolios, inherited units, and small
multi-state holdings are poorly served — too big for spreadsheets, too small
for enterprise platforms priced and shaped for larger operators.

This system fills that gap.

──────────────────────────────────────────────────────────────────────────────
WHO WE HELP
──────────────────────────────────────────────────────────────────────────────

A good fit:

  • 5–30 doors, often family-owned or informally syndicated
  • Operators who want clear records, not feature bloat
  • People who value a direct relationship with someone who understands PM ops
  • Owners moving off Excel or reducing dependence on over-scoped SaaS

Typical faces of that fit (see Wiki → Personas for full stories):

  • Diane — inherited family doors; needs kitchen-table-defensible statements
  • Raj   — part-time landlord; short evening sessions, menu-driven close
  • Elena — small PM firm; ROI math vs enterprise SaaS; inspectable books

Probably not a fit (today):

  • Large PM companies needing full tenant portals and marketplace integrations
  • Operators who want zero human involvement
  • Anyone expecting a mobile-first consumer app out of the box

──────────────────────────────────────────────────────────────────────────────
WHAT WE OFFER
──────────────────────────────────────────────────────────────────────────────

Consulting & integration — not shrink-wrapped anonymous SaaS.

  COLD-START SETUP & GO-LIVE
    Portfolio structure (owners, properties, units, current tenants & leases),
    fee settings, letterhead, first clean monthly cycle from go-live forward.
    Books start empty of balances — no historical payment import.

  CONFIGURATION & TRAINING
    Operator menu walkthrough, rent cycle, work orders, owner statements,
    backup and recovery basics.

  ONGOING STEWARDSHIP (optional)
    Periodic reconciliation review, statement QA, schema/docs refresh,
    backup visibility, light support.

  HOSTING (optional)
    Dedicated environment with operator access and export assistance as
    described in written scope (not a blanket uptime SLA).

──────────────────────────────────────────────────────────────────────────────
CONTINUITY & ACCESS TO YOUR BOOKS (PUBLIC-SAFE · DESIGN LANGUAGE)
──────────────────────────────────────────────────────────────────────────────

  This is a small human practice — not 24/7 platform support, not a bank,
  escrow, CPA firm, or insurer. Site and wiki language describes how we
  *design* the work. Only a written scope / engagement note is binding for
  a particular customer. If website copy and written scope differ, the
  written scope controls.

  Designed for (when hosting/stewardship is active as agreed):

  • Host reachable for day-to-day menu use while fees are current and the
    host is healthy — not an uptime guarantee
  • Office = menus + books on that environment (not rented opacity)
  • Period owner packages from in-system activity when a close is run;
    customer should keep local copies
  • On reasonable written request during an active paid engagement, and at
    normal wind-down: SQL dump of that instance’s books + packages we
    produced for closed periods — operational portability, not a guaranteed
    one-click import into a named third-party SaaS

  Not promised:

  • Same-day multi-month coverage, pager duty, or zero-impact if the steward
    is unavailable for a season
  • Immortal unsupervised hosts; every failure mode eliminated
  • Legal escrow, insurance products, or fiduciary custody of funds
  • Open-ended business-interruption damages (practical remedies when they
    exist: restore, correct posts, export) unless a signed engagement says
    otherwise

  Customer duties (plain): review packages before owner send; retain copies;
  protect logins; report suspected access compromise promptly.

  Data handling (plain): we process portfolio operations data you supply
  (owners, units, tenants, rents, work orders, ledger activity, contacts as
  entered) to run the system, produce packages, back up the instance, and
  support the engagement. We do not sell that data. You remain responsible
  for how you collected personal information and what you send onward.

  Full customer-facing HTML: site/services.html § Continuity.

──────────────────────────────────────────────────────────────────────────────
COLD START / STATEMENTS (SAY THIS OUT LOUD)
──────────────────────────────────────────────────────────────────────────────

  We start cold and go forward. Pre-go-live history stays in your old files.

  Owner statements show only activity that was invoiced and collected (or
  work-order billed) inside this system. If it never entered the PMS, it is
  not on the statement — by design, not by accident.

  We do not rebuild multi-year ledgers from spreadsheets. That is archaeology;
  this service is operations from go-live.

──────────────────────────────────────────────────────────────────────────────
HOW WE WORK
──────────────────────────────────────────────────────────────────────────────

  Transparency   — inspectable scripts, documented schema, explainable outputs
  Accountability — real operators behind the work, not an opaque platform
  Proportionality — tools sized to the portfolio, expanded only when needed
  Data respect   — exportable books by design; written export process;
                   no artificial lock-in narrative (not a legal warranty)

The operator menu (pm-menu.sh) is deliberately clear — some call it retro;
we call it honest. You can see what the system does.

──────────────────────────────────────────────────────────────────────────────
WHAT MAKES US CREDIBLE
──────────────────────────────────────────────────────────────────────────────

  • Active domain knowledge from scaled family operations
  • Working system in production — not a slide deck
  • Live documentation generated from the actual database ([do] Refresh Docs)
  • Full rent → payment → owner statement → work order → expense lifecycle

──────────────────────────────────────────────────────────────────────────────
GETTING STARTED
──────────────────────────────────────────────────────────────────────────────

  1. Conversation — portfolio size, current tools, pain points, go-live month
  2. Scope — cold-start setup vs ongoing stewardship (written)
  3. Pilot — one clean monthly cycle from go-live before long-term commitment

Contact through family referral or direct inquiry.

For technical architecture : Wiki → Platform Strategy
For feature list           : Wiki → Main Features
For target personas        : Wiki → Personas

──────────────────────────────────────────────────────────────────────────────

"We serve operators whom enterprise software was never meant to serve —
 with rigour, transparency, and people who understand the work."