Compound management software in Egypt
Units, residents, maintenance and dues in one place, across one compound or fifteen — instead of a different spreadsheet per compound, each on a naming convention invented by whoever built it.
The pattern is always the same. One spreadsheet for available units in the first compound. Another for the second, on a different naming convention because a different person built it. A reservations sheet that only one manager can edit without breaking the formulas. A WhatsApp tab with forty-one unread chats from residents.
None of that is incompetence. It is the predictable physics of running a large operation on tools that were never connected to each other. The fix is not more discipline — it is one record per unit that every department reads and writes, with the views each of them actually needs.
What it holds
- Every unit, every compound — one inventory with a single naming convention — status, price, floor, view, hold, sold — so a unit cannot be sold twice.
- Residents and handover — who owns what, when it was delivered, and what is outstanding, on the same timeline the construction team reads.
- Maintenance requests — logged against the unit rather than lost in a chat thread, with a status the resident can see without phoning anyone.
- Dues and collections — what is owed this month, by whom, computed from the same record finance closes the month on.
Where compound operations actually leak
Every handoff between disconnected tools is a leak. A unit gets sold twice. A maintenance request is agreed in a WhatsApp thread and never reaches the team who would do it. A resident calls about their dues and nobody can find the file in under ten minutes.
The leaks are rarely dramatic — they are a slow, constant bleed of data and goodwill that never shows on a single screen, because there is no single screen. The system's job is to be that screen.
Systems we have already shipped
- Premium Homes — curated commercial real estate across Greater Cairo.
- IGBS — a 17,000-record portal in eight modules — four years live with zero outages.
- The long version — how six disconnected sheets become one system.
How a project runs
- We start with the friction, not the feature list — where the current setup actually breaks, and what it costs when it does.
- A written scope: which modules go in phase one, what each one does, the timeline and what is explicitly out.
- We build in phases, so one department is live and useful before the next starts. You see working software early, not a demo at the end.
- Handover in your name: code, database, hosting and documentation. You can move all of it to another team without asking us.
Common questions
We manage several compounds on different conventions. Is that a problem?
It is the normal starting point. Reconciling the conventions is part of the first phase, and it is usually the step that surfaces the discrepancies nobody knew were there — duplicate units, unit codes that mean two different things in two files.
Can residents log in themselves?
Yes, and it is usually worth it. A resident who can see their own dues, requests and documents stops generating the calls your team currently absorbs — the same effect a buyer portal has for developers.
How long does it take?
Six to twelve weeks for a first working version. We start with inventory, because every other module references it, and put one department fully live before opening the next.
Do we own it?
Yes — code, database and hosting, all in your name, transferable to another team without our permission.
Related systems
- Developer ERP — the full operations layer — sales, finance, brokers, dashboards.
- Real estate CRM — the sales layer on top of live inventory.
- Buyer portal — the customer-facing login.