Real Estate Platform

In a real estate company the data never lives in one place. Properties, owners, developers, clients, requests and deals are created by different teams and change at different speeds, while the catalogue has to stay current, marketing needs its content, brokers need their pipeline and managers need their numbers.

We built one platform for all of it: a public website, a mobile app, an internal CRM and an integration layer to the company's existing system. The client, the product and the region stay undisclosed under NDA, so the images here are an illustration of the catalogue and a diagram of the architecture, not screenshots of the product.

The public site is server-rendered for search engines and a fast first screen. Every filter lives in the URL, so a search can be saved, shared or reopened, and meaningful combinations get their own landing pages. Property pages carry media, a map, the responsible broker and similar offers; the site also covers residential complexes, developers, articles and vacancies, in several languages.

A saved search becomes a subscription: when a matching property appears, the user gets a push, an email or an SMS.

The iOS and Android app is built with Nuxt and Capacitor on the same GraphQL contracts as the website, so the two channels never drift apart and the team does not maintain a second client from scratch.

It still behaves like a native app: phone confirmation and social sign-in, tokens kept in the device's secure storage, sessions that restore themselves, the system share sheet, deep links and push notifications. A small separate service routes every shared link to the right place — the screen inside the app, the store if it is not installed, or the web page.

Brokers, managers, back office, content editors and leadership each see the sections and actions their role allows. Properties are linked to owners, complexes, developers and agents, with media, map coordinates, bulk import and an approval flow for changes that need a second pair of eyes.

Around them sit clients, leads, requests and deals with merged duplicates and a full change history, tasks and a calendar, invoices and a cash desk that keeps euro and USDT balances side by side, XML exports to listing portals, and dashboards with KPIs for each role.

The hardest part was the company's existing system: the business ran on it, so it could not be switched off and migrated in one night. We built a separate sync service that takes its webhooks and reads its database changes through Debezium CDC.

The sync service never writes into other services' databases. It publishes normalised events, and each domain service applies them within its own boundaries — so the old and new systems could run side by side while processes moved across one by one.

Everything the user does not have to wait for goes through RabbitMQ: media import and processing, synchronisation, subscription checks and notifications. Notifications are split into a business layer that decides who gets what, and a transport layer that only delivers email, SMS and push, so a provider can change without touching the rules.

All clients talk to one gateway that federates the domain services into a single GraphQL API. The infrastructure is written in Terraform and runs on Kubernetes, with every service in its own Helm chart.

Vue · Nuxt · TypeScript · Capacitor · NestJS · GraphQL · Apollo Federation · PostgreSQL · Redis · RabbitMQ · Debezium · Kubernetes · Terraform · AWS