PortföyDijital: Engineering a Connected Real Estate Operations Platform

We started with the people doing the work.

We approached PortföyDijital from a real estate advisor's point of view.

An independent agent may show a property in the morning, answer buyer questions between appointments, speak with property owners and review advertising enquiries at the end of the day. Finding time to open and update five separate systems is not always realistic.

That led to an early product decision: the mobile experience should be a product in its own right, not a compressed version of a desktop dashboard.

We used Expo and React Native to build a mobile application organised around the tasks advisors perform throughout the day. Customer conversations, listings, appointments and follow-ups belong in the same working environment.

An advisor needs to understand what a buyer wants, find an appropriate property and continue the conversation without constantly switching applications.

An office owner needs a different perspective: oversight of advisors, listings, customer activity and appointments. Platform administrators have responsibilities such as organisation management and operational controls.

Instead of forcing all three roles into one interface, we designed experiences around their responsibilities. Those distinctions also shape access permissions, data ownership and business rules, not just the navigation menu.

Shared listings. Protected information.

One of PortföyDijital's central ideas was that an advisor's opportunities should not stop at the listings held by their own office.

Imagine an advisor who knows exactly what a client wants but cannot find a match in their agency. Another participating office may have the right property.

Without a structured collaboration model, that opportunity depends on personal relationships, group chats and the right people speaking by chance.

We wanted collaboration to be part of the product rather than an external workaround. The platform was designed with a shared property network through which eligible listings can be discovered across participating offices.

The difficult question was deciding what may be shared and what must stay private. Another office can discover an eligible listing without gaining access to the listing office's client conversations, internal records or staff information.

We designed a PostgreSQL-based multi-tenant data model with explicit ownership and access boundaries for organisations, memberships, advisors, communication channels, clients, conversations and listings.

Database security policies, role-aware operations and application permissions help maintain those boundaries.

There was also a question easily missed until later: when an advisor works with a listing owned by another office, how should the contribution and transaction be recorded?

The listing owner's rights and records need protecting while the collaborating advisor's involvement is represented accurately. We treated cross-office activity and attribution as part of the data model, not as a spreadsheet problem to solve after launch.

The network makes cooperation possible. The architecture makes it manageable.

From a WhatsApp message to a real customer relationship.

Property enquiries rarely arrive as perfectly structured forms. One buyer shares a listing link and asks a short question. Another describes their budget and preferred neighbourhood. Someone else wants to know whether a viewing is possible on Saturday.

The useful information is there, but inside a natural conversation rather than a database row.

We developed a communication layer to connect those conversations with the rest of the platform. WhatsApp conversations feed into the application, with incoming events routed through n8n workflows. Before processing proceeds, the relevant channel, organisation and advisor are resolved.

This is essential in a multi-tenant system. Sending a message directly to a language model is not enough. The platform must first establish which office owns the conversation, which customer record it relates to and what information the workflow may access.

The interaction can then connect to central CRM records. Customer preferences, conversation history, property criteria and follow-up information are evaluated in a shared operational context.

Depending on the enquiry, automation can query suitable properties, prepare listing information, assist with proposing a viewing time or hand off the next action to the responsible advisor.

We designed these as steps in one process instead of generating disconnected messages and records.

The outcome is not simply an automated WhatsApp reply. A customer conversation can become structured, traceable work.

AI assists. It does not make every decision.

We wanted AI to reduce repetitive work without taking consequential decisions away from the people responsible for them.

Understanding a customer message is one task. Finalising a price negotiation on an advisor's behalf or making a binding appointment commitment is another. We did not treat them as equivalent.

Language models can help interpret messages, identify customer intent, retrieve relevant context and draft responses. Access rights, record updates, workflow states and condition-dependent actions remain governed by explicit business rules.

Asking a buyer what times suit them does not mean a viewing has been confirmed. The application has to preserve that distinction.

An advisor must also be able to take over a conversation when professional judgement or personal contact is needed. Automation should help rather than obstruct that handoff.

n8n became the orchestration layer connecting messaging events, CRM context, data queries, property suggestions, notifications and outgoing replies. We built around real data and defined rules rather than leaving the entire real estate operation to a chatbot's improvisation.

Keeping advertising enquiries connected throughout the journey.

Attracting attention to a property is only the beginning of acquiring a customer. The steps that follow determine whether that interest becomes a real opportunity.

We therefore considered advertising requests and Meta-related operations as part of the wider product experience, not a disconnected agency service. An advisor or office owner should be able to initiate advertising-related requests in the environment where they already manage clients and listings.

We also designed management-side processes for reviewing and handling those requests.

Our larger goal was continuity. A property seen in an advertisement may trigger a WhatsApp message. That message can connect to a CRM record, a listing recommendation and eventually a viewing appointment.

These steps should not remain unrelated entries in an advertising dashboard, messaging app and spreadsheet.

This approach also shapes measurement. Campaign impressions alone do not explain what happens after a potential buyer makes contact. Connecting CRM records and operational processes creates the foundation for understanding what happens later in the customer journey.

Making property location data genuinely useful.

A property decision involves more than the features shown in a listing. Access to schools, healthcare, public transport, shops and everyday services can matter as much.

We added capabilities for working with location and proximity data. Property coordinates can be associated with nearby points of interest and available transport information.

This allows an advisor to provide more useful context when discussing a property with a prospective buyer.

There is a clear limit: missing location data must not become a fabricated journey time. Where reliable information is unavailable, the system should preserve that uncertainty.

It reflects a broader principle of the project: business software should make information more usable without pretending to know what it does not know.

Two application experiences. One product.

As PortföyDijital developed, it had to support both fieldwork and the work carried out in the office. We built two complementary application experiences.

The web platform uses Next.js and TypeScript. It provides a structured environment for accessing the product, managing organisations, listings, customers and operational responsibilities. Office-level and platform-level tasks can be handled through the appropriate screens.

We developed the mobile application with Expo and React Native. Its focus is on people working throughout the day with customers, listings, conversations and appointments. Advisors, office owners and administrators have distinct navigation and interaction flows.

The goal was not to keep two separate client and listing databases constantly synchronised. Both applications were designed to work with a shared data architecture and common business logic.

A conversation, listing, organisation or appointment should retain the same meaning and relationships regardless of the interface being used. That is what makes two experiences part of one product.

Engineering the service architecture behind the screens.

PortföyDijital required considerably more than front-end development. We needed a foundation for authenticated users, organisation-scoped records, messaging integrations, background tasks and incoming events from external systems, without making every component tightly dependent on the others.

We designed the application as separate but connected layers.

Next.js and React Native deliver the web and mobile experiences. PostgreSQL and the server application layer support structured records, authentication-related flows, permission-controlled access and server-side operations.

The messaging layer connects WhatsApp conversations to the application ecosystem. n8n coordinates work that needs to move between messaging, CRM records, property information, AI-assisted interpretation and operational actions.

We use Coolify to manage and deploy Docker services running on a Hostinger VPS. GitHub supports the version history and development workflow for the web and mobile application codebases.

The separation is intentional. Changing the mobile interface should not require rewriting a WhatsApp workflow. Adding automation should not mean rebuilding the customer database. Access rules should apply independently of what a particular interface displays.

We also worked on database migrations, workflow validation, role-specific tests and quality assurance across the applications.

That engineering work is less visible than a polished screen, but it matters when the platform needs to evolve without breaking its other parts.

Using MiroFish to challenge our own assumptions.

Building a technically capable product does not mean we already know how people will adopt it. We paid particular attention to that distinction while preparing for launch.

PortföyDijital combines several possible sources of value: a software subscription, cooperation across agencies, WhatsApp-assisted customer management and advertising operations. Each creates an opportunity and raises a separate question.

Would independent advisors use the platform in their day-to-day work, or return to familiar messaging habits after signing up? How useful would central reporting be if advisors did not maintain their records? Could an advertising service support adoption, or would manual operations limit growth?

Which would matter more in the early months: adding features or helping users reliably complete a few critical tasks?

We used MiroFish for pre-launch scenario simulations to examine those questions. Instead of relying on one optimistic forecast, we explored different adoption patterns, onboarding friction, support requirements, retention risks and the operational implications of combining software and services.

These simulations were not real customer interviews or proof of market traction. Their purpose was to challenge assumptions and identify questions that needed answering before scaling.

One lesson stood out: a long feature list means little if the product does not become part of users' daily work.

We therefore prioritised connecting the tasks that matter most: receiving an enquiry, finding the right property, arranging a viewing and keeping track of the follow-up.

MiroFish helped us interrogate business-model and launch scenarios. Product architecture and engineering decisions, however, remained grounded in actual requirements, source code and operational tests.

For Mihenk, this is also an example of using AI not just to build software, but to question the assumptions behind the software we build.

What we engineered.

The PortföyDijital engagement brought several disciplines together in one engineering effort:

The outcome: turning everyday operations into a connected software system.

The principal engineering outcome of PortföyDijital was a shared foundation connecting activities that usually sit apart in an estate agency's working day.

A property is no longer just a record on a listing screen. It can be part of a shared network, linked to an advertising request, discussed with a customer, recommended as a match and used to support a viewing appointment.

Likewise, a WhatsApp conversation need not remain locked in one person's chat history. It can be associated with a structured customer relationship, with relevant information available to the people responsible for the next step.

An office becomes more than a collection of disconnected advisor accounts. Staff, listings, clients and operational responsibilities are represented within one system, while the boundaries between independent organisations remain intact.

The mobile and web applications are not unrelated interfaces. They are different ways to work with the same operational processes.

What began as a problem of fragmented daily work grew into an engineering project covering product design, multi-tenant architecture, automation, data systems, AI integration and cross-platform software development.

PortföyDijital illustrates how a complex business operation can be translated into a connected software product.

For Mihenk Teknoloji, the project represents the work we aim to do: understand how a business really operates, make deliberate architectural decisions and build the systems that connect those operations.

Not technology for its own sake, but technology shaped around the work it is supposed to serve.