Lastfloors: a B2B network for real estate professionals

This is not agency work. It describes the backend built by Boygantech co-founder Mehmet Halil Mungan during a one-year role at Lastfloors, where the entire backend fell within that role. The role has since ended.

Live at lastfloors.com · iOS app on the App Store.

Starting position

In real estate, business starts with people knowing each other. A developer finding an agency to sell their project, an agent finding the right portfolio for a client, an investor seeing the right project — each depends on an introduction.

The traditional place for that introduction is the trade fair, and it has three problems. In Lastfloors’ own words, traditional networking is “expensive and complicated”:

• Tied to a calendar. A few days, a few times a year. In the months between, the network stops.
• Tied to geography. A developer in Istanbul reaching an investor in Dubai depends on both attending the same fair.
• Unmeasurable. Nothing records how many business relationships came out of the stand, the team, the travel and the printed material.

Decisions

Four member types, one data model

This was the first architectural decision. The system holds four parties: developers, agents and brokers, investors and investment trusts, service providers. Each looks for something different and shows something different.

Building them as separate applications is the obvious route; we rejected it. A network’s value grows with the number of edges — separating the parties cuts exactly the connections you are trying to create. Instead we defined a single company profile entity, with member type as an attribute of that profile rather than a separate table.

The gain: a connection between a service provider and a developer runs the same code as one between two agents. The cost: permission and visibility rules get complicated in one place. We took that trade deliberately — complexity concentrated in one place beats complexity spread across four.

The account is a company, not a person

The distinction looks small but it defines the whole product. Five consultants at an agency share one company profile; the portfolio, the connections and the conversations belong to the company, not the individual. When a consultant leaves, the network stays.

Billing follows from that: the Premium plan is seat-based and scales with member count.

Module gating tied to the plan

The free and Premium plans run the same codebase; the difference is which modules are open. Market analysis, AI search, job listings, posting to the feed and real-time chat unlock by plan level.

Building that as if premium checks scattered through each module would have become a permissions patchwork nobody could verify three months later. Capabilities are defined in one record, and both the API layer and the interface read from that source. Defining a new plan is configuration, not a code change.

Why chat lives on its own channel

Real-time chat is the one module that does not fit the request-response cycle. Building it by polling REST endpoints would have been both laggy and expensive.

Chat runs over a separate WebSocket channel, with session state and delivery information held in Redis. The real benefit of the separate channel is isolation: a spike in messaging load does not slow the portfolio and search endpoints.

One API, two clients

The web dashboard and the iOS app are served from the same Django REST API. The cost of maintaining two backends is not only the writing but the consistency: the same business rule interpreted differently in two places means mobile and web showing different things.

The price we pay is an API that has to serve both clients at once — less space on mobile, a richer view on the web. We solved that with versioning and field selection rather than by opening separate endpoints.

Delivery

Portfolio management

Users add, edit and publish their portfolio from one dashboard: detailed information, images and documents attach to each record. Image derivatives are generated on upload, so the user never thinks about sizing.

AI-assisted search

Building search on classic filter logic was not enough for this product: users search in sentences — “sea view, near handover, good for investment” — not in column values.

So search was built as a combination of semantic and keyword retrieval. Semantic search alone misses hard constraints (room count, budget ceiling); keyword search alone misses intent. Running both and reranking the result closes the gap between them.

Feed, job hub and referrals

Three mechanisms keep the network alive: a feed where companies post, a section publishing industry-specific job listings, and a referral programme where existing members invite new companies.

All three use the same notification infrastructure, and notifications are batched — sending one per interaction ends with notifications turned off entirely.

Privacy

The platform claims to be “secure and private”, and that is an architectural constraint rather than a marketing line: who can see a company’s portfolio, connections and conversations is enforced in the query layer, not hidden in the interface. When a record you have no access to is requested through the API, the answer is not “you lack permission” but “no such record” — the existence of a record is information too.

Measurement

There are no figures on this page, and that is deliberate.

The sizes the platform publishes on its own site (over 500 companies, over 1,700 connections, over 600 projects) are today’s numbers, and they cover a period after the role ended. They cannot be attributed to the engineering work described here, so they are not on the card.

These were the engineering metrics tracked during the role — the values are not public, so only what was tracked is listed:

• End-to-end delivery latency for a chat message; the long tail, not the average.
• Concurrent WebSocket connection count and reconnection rate.
• The response-time gap between the iOS and web clients on the same API endpoints.
• Click-through rate on AI search results, compared against classic filter search.
• Correctness of plan gating: the number of cases where a free account reached a Premium module (target zero).