Real Estate
How Techparser Built a Community Portal with a Custom CMS for a Property Owners' Association
Techparser built a community portal with a custom CMS for a property owners' association: staff build pages and forms, residents file requests and pay online.
- Client
- Property owners' association (US)
- Industry
- Real Estate
- Timeline
- Live in production
- Team
- 1 senior full-stack engineer
Results
- No-code
- Staff build pages and forms without a developer
- Versioned
- Each form edit saved; submissions keep their version
- Stripe
- Card and US bank-account payments with a ledger
The problem
A property owners' association needed a community website its own staff could run, and a resident area where owners find deed restrictions, submit forms, request paid house-checks while away, and pay online. The association's people and property records already lived in a separate legacy membership system, which stays the source of truth. The portal keeps its own copy of residents and properties in step with it automatically and creates resident logins as new contacts appear. Staff had to build pages and forms without a developer, and the schema had to keep evolving for years without losing old form submissions.
The portal is live for the association's whole membership. A bad sync could orphan or delete residents' accounts and history, and dues and house-check requests take real payments, so payment records have to be complete and trustworthy.
What Techparser built
- A scheduled one-way sync reads properties, contacts and their links from the legacy database in small batches and updates the portal's copy, creating a resident login when a new contact appears. A bad record is skipped and logged rather than blocking the run.
- A second job removes residents and properties that no longer exist in the legacy system, with everything attached to them, so the portal never shows people who have left.
- As the sync matured, the schema moved from user-centred records to property-centred ones, with documents, house-checks, payments and form submissions linked to the property.
- Every edit to a form saves a new version, and each submission stays linked to the version it was filled in on, so staff can change a form without breaking last year's answers.
- Staff manage nested pages, drafts, menus, the home page, sliders and FAQs, and each page can be limited to particular roles.
- Residents search deed restrictions by street address, with indexes added once the data grew large enough to make searches slow.
- Checkout supports cards and US bank accounts with instant verification, and payment notifications are verified against the raw request before they are trusted. Each payment records its breakdown, total, status, payer and property, including paid house-check requests.
- Staff queue large exports of users or payment history; a background job builds the spreadsheet and emails it, so a big export never times out a page. Lost-and-found pets, newsletter subscriptions and an email send log run as resident services alongside the CMS.
Decisions that mattered
A legacy system that stays the source of truth
The association's people and property records already lived in a separate legacy membership system, and Techparser chose to keep it authoritative rather than migrate off it. A scheduled one-way sync reads properties, contacts and their links in small batches and updates the portal's copy, creating a resident login when a new contact appears, while a second job removes records that no longer exist in the legacy system. The sync is deliberately gentle on the legacy server, and a bad record is skipped and logged rather than blocking the run. The trade-off is eventual consistency instead of a live join, in exchange for never putting load or risk on the system of record.
Forms that change without losing the past
Staff needed to build and edit forms for years without a developer, but old submissions still have to mean what they meant when they were filled in. Techparser built a versioned form builder: every edit saves a new version, and each submission stays linked to the version it was filled in on. Staff manage pages, menus and forms themselves, and the schema moved from user-centred records to property-centred ones as the data grew. The decision was to version rather than overwrite, which costs storage and some complexity but protects the integrity of historical answers that an association may need to rely on later.
Payments you can always account for
Dues and paid house-check requests take real money, so the payment records have to be complete and trustworthy. Techparser supported card and US bank-account payments with instant verification, and every payment notification is verified against the raw request before it is trusted, so a forged callback cannot mark something paid. Each payment records its breakdown, total, status, payer and property, including house-check requests. The decision was to treat the ledger as the authority on money movement rather than the payment provider's dashboard, so staff can answer any question about whether a payment went through from the portal itself.
Outcome
The portal is live in production at ropo.org for the property owners' association's whole membership. Staff run the community website through a custom CMS, building pages, menus and forms without a developer, while residents search deed restrictions, submit requests, book paid house-checks and pay online.
Because the legacy membership system stays the source of truth and the portal mirrors it on a schedule, resident and property records stay current without manual re-entry, and a bad record is skipped rather than allowed to corrupt the run. Because every form edit is versioned and every payment is recorded against its payer and property, staff can change a form without losing old answers and can answer any question about whether a payment went through.
Questions about this project
- What technology stack does the property management portal use?
- The portal has a React and Redux front end styled with Tailwind CSS, over a Node.js and Express back end that uses Knex against MySQL, with Stripe for payments. A scheduled job keeps the portal's copy of residents and properties in step with the association's legacy membership system. The stack supports a custom CMS, a versioned form builder, deed-restriction search and queued background exports.
- How does the portal stay in step with the association's legacy membership system?
- The legacy system stays the source of truth. A scheduled one-way sync reads properties, contacts and their links in small batches and updates the portal's copy, creating a resident login when a new contact appears. A second job removes residents and properties that no longer exist in the legacy system, with everything attached to them. The sync is gentle on the legacy server, and a bad record is skipped and logged rather than blocking the whole run.
- Can Techparser build a community portal with a custom CMS like this for us?
- Yes. Techparser built this portal end to end: the custom CMS for pages, menus and forms, the versioned form builder, deed-restriction search, the legacy sync and reconciliation, card and US bank-account payments with a complete ledger, and queued exports, live in production. We can build the same for your organisation, including the integration with whatever system already holds your records. Book a call to talk it through.
