Why a mobile app for an HOA gets stuck in paperwork and chats
A leak request in a building entrance lives simultaneously in the building’s messenger chat, the dispatcher’s notebook, and the chairman’s memory.
While it is forwarded between chats, the plumber learns about the problem a day later, and the resident receives confirmation only after calling again.
Tracking owner requests comes down to manually collecting screenshots: by the end of the month, no one can say how many requests were closed and how many are sitting without an assignee.
Paper rounds of building entrances add their own cost. Readings and notes are recorded on a sheet and then manually transferred into a spreadsheet — at this step, numbers are lost and discrepancies appear in charges, which are then sorted out with each resident individually.
General meeting minutes are often drawn up retroactively: the decision was actually made in a chat, and the document is assembled after the fact, adjusting wording and quorum.
As long as votes are not recorded at the moment of voting, challenging a decision rests not on facts but on who remembers what.
The work of an HOA dispatcher splits into parallel channels — phone, chat, paper. There is no unified queue, so an emergency request and a request to replace a light bulb sit in the same pile, and priority is determined by who called loudest.
An HOA mobile app changes not reporting but the route data takes: a request is registered at the moment it is submitted, readings reach billing without manual transfer, and a meeting decision is recorded together with the vote and timestamp. Let’s break down how this is covered — at the level of roles, access rights, and notifications.
What changes after the app launch: requests, readings, decisions
The app changes not reporting but the daily cycle of handling requests.
A request from an owner’s personal account immediately becomes a work order with a responsible person, deadline, and photo evidence — the dispatcher does not retell it by phone or look for a contractor in chats.
Response time shrinks from days to hours, and the share of requests closed on time stops depending on who is on shift that day.
Online meter readings remove the most labor-intensive step: residents enter data themselves, the system checks it for outliers and pulls it into the calculation.
The volume of manual transfer drops to selective reconciliation, and billing notifications go out addressed and itemized — typical “where does this amount come from” questions stop reaching accounting.
Owner voting moves entirely into the app: agenda, materials, vote, counting, and minutes are generated in one place. Quorum is visible in real time, so a meeting does not fail due to a lack of votes, and decisions are formalized without manually consolidating ballots.
Before launch, we record baseline values: median response time to a request, share of requests closed on time, number of manual operations when entering readings, and number of disputed charges for the period.
A month after launch, we compare — this shows which processes have shifted and where further refinement is still needed.
Implementation options: off-the-shelf solution, customization, or in-house development
The path depends on what is already working in the association.
If accounting is kept in spreadsheets and chats, it is faster to connect a ready-made platform; if an accounting system is already implemented, it is more reasonable to customize it — reference data, accounts, and charges remain in one environment, without exports and discrepancies between databases.
In-house development is justified when scenarios are non-standard: multiple billing centers, custom charging rules, integrations with meters and an access control system.
The difference between the options shows up at the support stage, not launch.
A ready-made platform follows its developer’s cycle, customization follows the accounting system’s update cycle, and in-house development requires its own maintenance and release of updates for new operating system versions.
| Option | When it fits | Limitations |
|---|---|---|
| Off-the-shelf solution for an HOA | Standard scenarios: readings, charges, requests; launch needed in a short time | Charging logic is set by the developer — to fit your rules, you will have to change the process itself |
| Customization of an accounting system | Accounting is already kept in 1C or an equivalent, and data and reference records live there | The mobile part is tied to the platform version and its updates |
| Development from scratch | Non-standard rules, multiple billing centers, custom integrations | Longer to first release, and you need your own support team |
| Mobile web account | Quickly test demand and cover the active portion of owners | No offline operation or system notifications; publication in app stores is not required, but neither is presence there |
A mobile web account is often taken as the first step: it gives live feedback from owners before investing in native development.
If the results make clear that notifications and stable operation on a weak connection are needed, the account is moved into an app with publication in app stores — the same backend, a different shell.
Implementation stages: from process audit to access handover
The first step is not a prototype but a description of how the building is managed now. We gather interviews with the chairman, accountant, and manager, analyze who initiates a request, at which step it gets stuck, and which reports are still assembled manually.
The output is a map of roles and operations that determines the app’s composition, not the other way around.
- Audit of building management processes. We record scenarios: a request and its statuses, meter readings, charges and debt, announcements, owner votes. We note where data is entered twice — these places are automated first.
- Data and reference-data schema. We describe entities: building, premises, owner, account, charge, request, meeting decision. We agree on rights to personal data: who sees a specific apartment, and who sees only aggregated building-level indicators.
- Setting up integrations and roles. We connect the app to the billing accounting system and owner registry, and define roles — owner, chairman, accountant, field specialist. We reconcile the debt import line by line: an account mismatch will surface in the very first complaint.
- Trial launch on one building. We deploy a limited scope: some owners, real requests, real charges. We look at how many requests are closed inside the app, how many inquiries go to chat and calls, and how notifications behave under peak load.
- App acceptance. We run a checklist through role scenarios, check recovery after failure, correctness of charges after re-import, and operation on a weak connection.
- Handover of access and documentation. We hand over administrator accounts, the procedure for updating reference data, the integration schema, and the actions to take when data discrepancies occur. After that, the building maintains the app itself, and our role is support.
We structure the stages so that each ends with a verifiable artifact: a process map, a data schema, a working scope on one building. This allows the project to be stopped at any step without redoing it from scratch.
What remains with the client: configuration, schemas, procedures, and access
The app is not the only artifact of the project. After launch, the client retains a set with which the system can run without us: configuration, integration descriptions, access policies, and documents for three audiences — the dispatcher, contractors, and owners.
- Configuration of the app and admin panel: building and account reference data, tariffs, notification templates — edited through the interface, without code changes.
- Integration schemas with billing, payments, intercom, and barrier systems: exchange format, synchronization schedule, behavior when the external system is unavailable.
- Access policies and roles: owner, board, dispatcher, accountant, contractor — what each role sees and changes, who grants and revokes rights.
- Dispatcher work procedure: receiving and distributing requests, response times, escalation, response templates, actions during an emergency.
- App documentation: description of screens and logic, changelog, build and release procedure, test environment requirements.
- Instructions for owners: guides on registration, payment, readings, and requests — in the app and on a printed stand in the building entrance.
- Backup procedure: what is backed up, how often, how long recovery takes, who checks the backups.
We hand over the set so that any contractor can take it over — without details tied personally to our engineers. The client makes edits to procedures and roles independently; we step in when a task goes beyond standard settings.
Case study: how the board eliminated paper rounds and lost requests
How it was: a resident request turned into a paper record
The board served 12 buildings and conducted rounds using paper logs. The plumber and electrician recorded faults in a notebook once per shift and then copied them into the dispatcher’s log — 30-40 inquiries passed through this way per shift.
Some records were lost during shift handover: the resident did not see the status, called again, and the average response time for a leak or a stuck elevator stretched to two days.
What we did
Accounts and charges remained in 1C, and the app was made a separate layer: a request is created directly during the round, linked to the building, entrance, and type of work, and assigned a contractor and deadline.
Before and after photos settle the quality dispute, the status is visible to the resident and chairman simultaneously, and an overdue request goes to the responsible person.
The key is not the screen itself but the routing rules: an inquiry without an assignee surfaces to the dispatcher after an hour, and one closed without a photo automatically returns to work. The paper log stopped being the only source of truth.
What changed
Per shift, 90-120 inquiries pass through the app instead of 30-40: rounds are recorded on site, not from memory in the evening. Response time for an emergency request dropped from two days to 40 minutes, and the share of inquiries closed on time rose to 94%.
There are no lost requests — each has a number, assignee, and change history, and a building export is assembled in a minute instead of reconciling logs.
What to do if a request tracking system is already deployed in the building
A full replacement of a working tracking system is a bad scenario: while migration is underway, the dispatch office lives in two realities, and residents do not understand where their request went.
The app integrates into the existing scope as another workstation — requests, work orders, and reference data remain where they are used to keeping them.
The first task is migrating reference data, not requests. Buildings, entrances, premises, accounts, tariffs, categories, and assignees are exported once, checked for duplicates and discrepancies, and then live in one place — in the accounting system as the source of truth.
If accounting is kept in 1C or still in spreadsheets, data migration from spreadsheets follows the same scheme: we analyze the structure, map fields, and separately process disputed accounts — otherwise duplicates appear after launch.
Next, integration with the accounting system is assembled, and its goal is to eliminate double data entry. A resident closes a request — the status, comment, and photo go to the accounting system; a dispatcher changes the assignee — the change returns to the app.
Where the system’s external interface is flexible, exchange is event-based; where it is limited, we put in a middleware layer that transfers changes in batches via the exchange log.
Phased connection of buildings removes the main risk. On the pilot building, you can see how reference data, access rights, and notifications behave, and mapping errors are caught at a small volume.
The remaining buildings are connected in waves, and the previous request intake channel works until full reconciliation — rollback does not require stopping service.
Technical concerns: integrations, access, and dispatcher workload
At acceptance, the board leader asks the same questions: how the app will coexist with accounting, who is responsible for owners’ personal data, whether the dispatcher’s workload will grow, and what happens when the connection is lost in the basement. Below are short answers for each node.
How is the app connected to charges and accounting?
Exchange runs on a schedule: accounts, charges, payments, and debt are pulled from the accounting system — the owner sees their own figures, not correspondence with the accountant. A completed payment returns to accounting, and there is no need to reconcile receipts manually.
If accounting is kept in an external service, we connect via file export or a secure software interface.
How is residents’ personal data protected?
Data is separated by roles: an owner sees only their apartment and their account, the chairman sees a summary, and the dispatcher sees requests without extra fields.
Access to the registry is logged, transfer goes over an encrypted channel, and consents to processing are recorded in the app. When choosing infrastructure, we take into account requirements for data storage within the country.
Will the dispatcher’s workload increase?
Requests arrive in one window with address, type, and photo — the dispatcher does not ask again or transfer them from messengers.
Routing by entrance and type of work, response templates, and auto-confirmation of receipt remove routine: at the start, the flow usually grows but is handled by the same staff.
What happens on a weak connection?
The app works offline: it shows saved charges and accepts requests into a local queue. As soon as the connection returns, records go to the server without duplicates or loss of order. This is important for basements, parking garages, and old buildings with poor coverage.
Who supports the app after launch?
After handover, a procedure remains: updates for new mobile system versions, availability monitoring, SLA incident handling, and enhancements as tasks grow. The board does not need its own engineer — a person responsible for request acceptance is enough.
Let’s discuss the task: we’ll review the processes and come back with an estimate and plan
Describe the task — how many buildings are in scope, which HOA processes you want to move into the app, and who will maintain data on apartments and charges.
On the first call, we review these inputs and clarify what already exists: accounting exports, the owner registry, and current communication channels with residents.
Send access to this data or an export of it — that way the timeline estimate will rely on the real structure, not assumptions.
After the call, we come back with an estimate and work plan: which modules we cover in the first phase, what moves to the second, and where integration with existing accounting systems will be needed.
We separately discuss risks — registry quality, the share of owners without smartphones, and the load on the chairman during launch.
- Scope diagram: roles of resident, chairman, accountant, and contractor, access rights to personal data
- First-phase composition: requests and emergency calls, meter readings, announcements, owner votes
- Work plan with stages: registry assembly, development, trial operation, handover to production
- Timeline estimate by stage and a list of data needed from the HOA at each step
- Procedure for a trial launch on one building: how to compare the number of requests and response time before and after
- Support and development scheme: updates for new system versions, enhancements based on resident requests, failure handling
We suggest starting with a trial launch on one building — this gives live figures on load and a clear list of edits before rollout across the entire scope.
Then we move the remaining buildings according to the proven scenario and take the app into support and development: updates, enhancements, and request handling. Describe the task in a convenient format — we’ll come back with an estimate and plan.