Platform map — one platform, separate modules
Can the property management system and the agency system live in one system? Yes — one platform with separate modules. They share the boring parts (login, people, properties, files, notifications) and keep the sensitive parts apart (money ledgers, client records, compensation).
1 Picture it
Zentra · Agency module
Estate agency practice (registered EA)
- Agents, hierarchy, referrers
- Commission + Marketing Bonus + override
- Claims, payouts, vouchers
- Letters, e-sign, stamping
Mr Tanah · Property management module
Management, tenancy, renovation
- Units, tenancies, bills, deposits
- Maintenance + renovation jobs
- Owner statements, 10% management fee
- Listing records
Zentra · Project sales module
New project sales
- Project pages, EOI, bookings
- Developer liaison, HIMS / e-SPA
- Agent allocation by project
▼ all three sit on one core ▼
Shared core (build once, use by all modules)
- Login & roles (Agency Head, Leader, Agent, Client, Tenant, Owner)
- One people registry — a landlord who is also a seller is one record
- One property registry — the same unit keeps one ID across modules
- File storage + document archive with IDs
- Notification service (WhatsApp / email / Telegram)
- Audit log — who did what, when
- Backups and monitoring
2 What is shared, what must stay apart
| Layer | Shared in one platform? | Why |
|---|---|---|
| People & properties | Shared | One owner, one unit — no duplicate records, one history |
| Login, roles, audit log, files, notifications | Shared | Build once; agencies and management need the same plumbing |
| Documents & e-signature | Shared engine, separate templates | The signing engine is the same; the letterheads and clauses differ by entity and brand |
| Money ledgers | Separate | Management fee income, renovation income, agency commission and client money are different books, different TIN, different rules |
| Client money & deposits | Separate | Estate agency practice rules on client accounts must never mix with management collections |
| Agent compensation | Separate | Who earns what is confidential to the agency module — management staff must not see it |
| Branding seen by clients | Separate | A tenant sees Mr Tanah; a seller sees Zentra. One system, two front doors |
3 Why not simply put everything in one pile
Three real risks
- Entity & audit risk — one set of books for two businesses is hard to defend in an audit or tax review.
- Confidentiality risk — commission structures and client deposit records leaking across teams.
- Blast radius — one bug or outage stopping collection of rent and agent payouts at once.
What you gain by keeping one platform
- One login, one app to train staff on, one backup and monitoring setup.
- One server bill instead of two — roughly half the running cost.
- Cross-sell happens naturally: an owner managed by Mr Tanah is offered the agency to sell; a buyer becomes a managed tenant.
- Later, the agency module can be licensed to other agencies on its own without touching Mr Tanah.
4 How we get there without rebuilding twice
| Step | What we do now | Why it matters later |
|---|---|---|
| 1 | Every document gets an ID (ZTH-LOAR-000101) and every deal a deal ID | Records can move from Sheets to a database without renumbering |
| 2 | One people list and one property list, used by both MT and Zentra work | Migration becomes a copy, not a reconciliation exercise |
| 3 | Keep modules separate inside the existing setup (separate Sheets and files per module) | Each module can be lifted into the web app one at a time |
| 4 | Upgrade to the web app when a trigger fires (30+ agents, 2,000+ documents a year, client portal needed) | No wasted spend before it is needed |
Recommendation: one platform, three modules, share the core, keep the money and the brands apart. Build the MVP module by module on the setup we already pay for, then lift all three into one web app together when the triggers say so — not before.