Skip to main content
Our services

Property developers & management

From sales through to managing delivered residences — a platform covering the whole cycle.

Angular Node.js Flutter MySQL
Request a quote

We build platforms for property developers and residential managers in Morocco: sales tracking, a buyer portal, then management of the delivered portfolio — service charge calls, collections, a resident portal and a field application. The entry scope is a single business module from 40,000 MAD; a full multi-role platform runs between 120,000 and 500,000 MAD. We become relevant above a certain portfolio size, and we say so plainly below.

Condominium accounting is now regulated

Decree no. 2.23.700 of 23 January 2025, published in Bulletin Officiel no. 7391 of 31 March 2025 under law 18.00 on the status of built condominiums, sets a standardised chart of accounts for condominium management. It applies from the first fiscal year opened after its publication — for a condominium whose year follows the calendar, that means the year opening on 1 January 2026.

Two points we are asked every time. There is no minimum unit threshold: every condominium is covered, whatever its size. And the three tiers of accounting obligation are set by annual charges called — not by number of units, and not by amounts actually collected — with thresholds around 200,000 MAD and 500,000 MAD.

For a manager running several residences this shifts three things: how charges are called, the traceability of receipts, and the ability to produce accounts for a general meeting without rebuilding them by hand. This is not a general accounting problem — it is a condominium management problem, where every entry is attached to a unit, an owner and a financial year.

The moment the tooling runs out

The signals are always the same. Sales tracking lives in a spreadsheet three people edit at once. Service charge calls go out late because they have to be reassembled every quarter. Collections depend on one person’s memory. Resident requests arrive by WhatsApp and get lost. And at the general meeting, half the time goes on justifying figures instead of making decisions.

None of this is a motivation problem. These are role problems: four different jobs — sales, management, accounting, field staff — working on the same objects without a shared tool.

What we build

  • Sales tracking — programmes, phases, units, reservations, options, cancellations, and the real state of stock at any moment.
  • Buyer portal — payment schedule, calls for funds, contractual documents, construction progress. This is what cuts inbound call volume.
  • Delivered portfolio management — units and owners, per-residence budgets, charge calls, receipts, staged reminders, year-end accounts presented against the standardised chart.
  • Resident portal — account position, payment, incident reporting, general meeting documents.
  • Field application — interventions, readings, timestamped photos, work orders, including offline on site.
  • Reporting — arrears by residence, debt ageing, collection rate, budget versus actual.

What the standardised chart changes in the software

Moving from spreadsheets to standardised condominium accounting is not a change of presentation. Four mechanics have to exist in the software:

  • Systematic attachment. Every entry carries a unit, an owner, a residence and a financial year. Without it no account can be reconstituted and no dispute can be settled.
  • The apportionment key. Charges are split by ownership shares or by a key specific to the residence — lift, heating, common areas. The key must be a property of the residence, not a formula copied each quarter.
  • Voted budget against actual. The general meeting votes a budget; the year deviates from it. The variance has to be legible during the year, not discovered at close.
  • Year-end close. Accounts must come out in the expected presentation, with their annexes, without re-entry.

This is also what makes the general meeting shorter: when figures are traceable down to the document, the meeting is for deciding rather than justifying.

Collections, where the money leaks

Unpaid service charges are almost never a matter of bad faith: they are reminders that were not sent at the right moment. A platform for this has to produce three things — debt ageing per unit, staged automatic reminders (notice, formal demand, referral to the syndic council), and a timestamped record of every send, which is the useful evidence if the matter escalates.

The reporting we ship by default: arrears by residence, ageing, collection rate per financial year, and the list of units whose position has deteriorated since last month. That last one is what actually changes a manager’s behaviour.

Should you talk to us, or buy a product?

Seven syndic management products are available on this market, and for a manager running a few residences with standard processes, one of them is the right choice: it costs less than a build, it is available immediately, and its limits will not get in your way.

We become relevant when one of these is true:

  • Portfolio size makes the per-unit cost of a subscription product exceed that of an owned platform.
  • You do both jobs — developer and manager — and want one system from unit sold to unit occupied, without double entry.
  • A process is specific to you and you do not want to bend it to a product: a particular collections mechanism, a non-standard charge apportionment, an internal approval chain.
  • Integrations are essential: existing accounting, banking, electronic signature, a group ERP.

If none applies, we will point you to a market product. A project sold to a client who did not need one ends badly for both parties.

How we start

With a five-day diagnostic: mapping of roles and permissions, an inventory of integrations, regulatory flows, a prioritised backlog and a costed scope. The document is yours whether or not you continue with us, and it is credited in full against what follows.

Then, almost always, a business module before the full platform: the most painful scope first — usually charge calls or sales tracking — in production within six to ten weeks. It is the same code that grows afterwards; nothing is thrown away. See business platforms for the full logic, and our pricing for the ranges.

Personal data

A resident portal processes personal data: identities, contact details, arrears situations. The CNDP declaration and the matching technical configuration — who sees which file, what is logged, how long data is kept — are part of the project, not a later remediation. See CNDP compliance.

Ready to start your project?

Let's talk about your operation: we scope the roles and integrations first, then we price it.

Chat on WhatsApp