InmoQueen is a real estate CRM for networks of agencies, in three parts: the app the agencies work in, the public listings portal, and a website per group. All three run on the same data, so a property loaded once in the back office is published on the portal and on the group's own site with no duplicated work and no drift between them.

A group keeps its own brand

A network can run under a subdomain or under its own domain, and the platform resolves which group it is serving at runtime, on the way in. The agency sees its own site; underneath, every office in the network is working in one shared back office. Reines is one of those group sites, live today.

Staff and the public are not the same kind of user and do not share an authentication path: the CRM has its own users and the web has its own clients, each with their own guard and their own Google sign in. Client sign in creates an account; staff sign in never does, it only links an existing one.

Publishing to the portals

A Spanish agency lives on Idealista and Fotocasa, so a property that is only in the CRM is a property that does not exist. Both are wired as real time syncs, plus an XML feed for ThinkSpain, and credentials sit at group level with each office able to override them or opt out.

The detail worth telling is the one that is not in any brochure. Editing a property fires an update per field, and syndicating each of those would mean hammering someone else's API while an advisor is still typing. So a change does not sync: it marks the property as needing one, and a job picks up everything that has been quiet for five minutes. Rapid edits collapse into a single push.

The other one is that the sync jobs write back with the observer silenced. Without that, the job updates the property, the observer sees the change, and dispatches the job again, forever.

The advisor's calendar has to be their calendar

Visits, meetings and tasks live in the CRM, but nobody is going to keep a second calendar. So it syncs both ways with Google Calendar and with Outlook, per user, over webhooks: a meeting moved on the phone moves in the CRM. Google and Microsoft do not agree on how to do this, which shows in the seams. Google's subscriptions last thirty days and Microsoft's about three, so both are renewed on a schedule, and Microsoft is done through delta queries rather than sync tokens.

Booking a visit, and reserving

Advisors declare their working hours, their breaks and their exceptions, and the public booking form builds the available slots from that, then removes what is already taken: calendar events, other visits, and anything in the past if the date is today. What is left is what a visitor can pick.

Reserving goes further and takes money. Deposits run through Redsys, which is what Spanish banks use, on a fork of the package that adds refunds. Before paying, the client has to accept the reservation policy, which is multilingual and falls back from the property to its office, and the payment button stays disabled until they do.

An API for the agency's own website

Some agencies already have a site and want to keep it. They get a token per group, with abilities, so their backend can read properties and developments, create clients and inquiries and reserve a property. Every query is scoped to the group that owns the token, and a foreign key pointing at another group's data is rejected rather than trusted.

Status

In production since 2025. The CRM is at app.inmoqueen.com and the portal at inmoqueen.com. It replaced an earlier application of the same name, and the clients from it were imported over.

The interface is multilingual through Laratext, one of my own packages, and properties can be published in several languages at once.