Knowing the property is not the same as knowing how to sell it.knowing how to sell it.

I started with the seller's actual job rather than the final listing screen.

The property moves through a preparation process before it becomes something a buyer should see. The seller has two ways to get there.

The manual route is a guided step-by-step flow through the core facts, pricing, location, rooms, building details, energy information, media, documents, visibility settings, and contact preferences. Required fields are validated at each stage, so the seller cannot move forward until that part of the property is complete.

The second route is Sellumo. Instead of working through the property only as a form, the seller can describe it naturally and build the same structured property state through conversation.

That route adds a different kind of value. Knowing a fact and knowing how to present it are not the same thing. A seller may know that the heating system was replaced, that the garden gets afternoon sun, or that a particular renovation matters. Sellumo can help turn those facts into a clearer, buyer-ready presentation, bring forward the details worth showing, and make the preparation process feel less technical.

Both routes work with the same underlying property model. The difference is how the seller chooses to prepare it.

The seller and buyer experiences still work around one underlying property model. The seller sees private preparation state while the buyer later sees the approved marketplace representation. Messaging, notifications, and AI can all reference the same property without creating competing versions of the truth.

A buyer can reach the owner directly from a property, but I did not model that first interaction as unrestricted messaging.

The first message creates a property-specific contact request and the conversation begins in a pending state. That gives the seller a clear decision point: accept the request and continue, or decline it without turning every inquiry into an active conversation.

Once accepted, the same thread becomes the shared communication space for that buyer, seller, and property. The application can therefore distinguish new interest, accepted contact, declined contact, and ongoing communication instead of treating every message the same.

The backend verifies that the current user is actually a participant before returning conversation data, and the request remains attached to the property that created it. That relationship becomes useful across the product: notifications know which property an inquiry belongs to, the seller understands the buyer's context, and later analysis can interpret the interaction against the property itself.

Once a request is accepted, the product behaves like a real messaging experience rather than a contact form with a thread underneath it.

Messages arrive through private realtime channels. Both sides can see when the other participant is online, when they are typing, and whether a sent message has been read. The interface updates optimistically for the sender while the backend remains responsible for persisting the message and updating the conversation state.

Presence is more than UI polish. The same online state becomes useful later when the product decides whether another notification or email adds anything. If the recipient is already inside the conversation, the system should not behave as if they are absent.

I also treated message history as user-specific state. A participant can remove an individual message from their own view without changing what the other person sees. A sender can remove their own message for both sides, and several messages can be selected and deleted together. At the conversation level, each participant can archive the thread independently, and new communication can bring an archived conversation back into the active workspace.

Those details turned messaging into a product domain of its own: realtime delivery, authorization, typing and presence, read state, per-user history, and shared conversation state all had to agree.

The communication system produces different kinds of events. The first message can be a new contact request, later messages are normal conversation events, and accepting or declining a request creates another state change the other participant should know about.

I built the notification layer around those differences. A notification can carry the actor, conversation, message preview, and property context, while users can control whether message and request events should also reach them by email.

The more interesting decision was when not to notify. Before creating another conversation alert, the system checks whether the recipient is online and already viewing that exact conversation. If they are, another notification adds noise without adding information.

That keeps the product responsive to what happened without ignoring what the user is already doing.

Sending an email immediately for every message would have been easy to implement. It would also tie messaging to an external delivery service and turn a short burst of chat into a burst of email.

I separated those paths.

When an offline notification may need email, the application creates a queued delivery item with its own scheduled time and state. A background worker processes it later, when the system has enough context to decide whether the email is still useful.

Before delivery, the worker checks the user's preferences again, checks whether they have returned online, groups related events by conversation, suppresses repeated email inside an anti-spam window, and builds a compact delivery instead of treating every event as a separate email.

Each queue item moves through an explicit sent, skipped, or failed state, so delivery problems can be monitored and retried without affecting the underlying chat.

Conversation deletion has two different jobs.

If one participant deletes a thread, the application can remove it from that person's workspace without immediately destroying the shared conversation for the other participant. When the final participant deletes it, the conversation moves into a separate archive process rather than being removed blindly inside the request.

At that point, an asynchronous AI analysis can work with the conversation and a reduced snapshot of the property it was about. The snapshot leaves out several operational or sensitive fields while preserving enough context to understand whether the buyer's questions, objections, and the seller's answers made sense in relation to the property.

The result is not another copy of the live chat. It is a smaller structured record of the signals inside the interaction: how the conversation developed, what the buyer cared about, whether negotiation appeared, which property strengths were used or missed, how clearly the seller responded, and what the likely outcome was.

Those signals can later support product analysis, evaluation, and seller-coaching design without making raw chat history the permanent analysis layer.

Only after the structured archive record is created does the operational conversation leave the live messaging data. The derived record then follows its own retention lifecycle.

This creates a cleaner separation between communication data, which exists to support the conversation, and derived intelligence, which has a different purpose and should be smaller and governed separately.

The seller should not need to know which internal capability handles a request. They experience one conversation. Underneath, property creation, market research, and general seller guidance have different data needs and different levels of authority.

I introduced an orchestration layer between the seller-facing experience and those capabilities.

Before deciding what should handle a message, the system loads the relevant seller and product context, including the active property, persistent seller memory, and any structured workflow already in progress. If the seller is halfway through a task, that workflow can resume before the message is treated as a completely new request.

For new requests, routing uses the strongest signal available. An explicit action in the product can provide intent directly. Deterministic routing handles clear cases. Model classification is reserved for genuinely ambiguous requests.

That avoids spending another model call on a decision the product already knows while keeping the flexibility needed for normal language.

The orchestration path is observable as well. The application records which route handled the request, where the routing decision came from, and whether a workflow was started or resumed. When something goes wrong, I can inspect the path instead of reducing the problem to “the AI answered badly.”

Sellumo is an additional creation path alongside the guided manual flow, not a replacement for it.

Property creation is where a chatbot approach breaks down quickly.

A seller may describe several useful facts in one sentence, skip something required, answer only part of a follow-up question, or return later to continue. The product still needs reliable structured data before it can create the property.

I built that flow as a resumable workflow rather than one long generation. The system extracts the information available in the latest message and merges it with the state already collected. Normal application logic then checks that accumulated state against the required property contract.

If something is missing, the workflow pauses and asks only for what is still needed. The accumulated state is persisted. When the seller replies, the same workflow resumes, merges the new information, and checks again. Only when the required state is complete can the workflow call the controlled application action that creates the property draft.

The same property model treats energy information as structured data and supports property documents such as floor plans, energy certificates, and other files linked to the property. That gives the product a strong foundation for making document-assisted setup more natural later without treating an uploaded file as unquestioned product truth.

Optional uncertainty can remain optional. Required data cannot.

Pricing is one of the easiest places for a private seller to feel confident and still be wrong. A number based on a neighbour's sale, renovation costs, or a few listings is not enough on its own.

I built the market capability so a pricing opinion cannot come before current evidence. When the seller asks what the property may be worth, wants help choosing an asking price, or already has a price in mind, the agent first researches the live market around that property.

The research works from the property's location and type and looks for the most relevant evidence available across the city, district, or neighbourhood, including €/m² ranges and local comparison signals. If the first path is too thin or incomplete, the system can broaden the live research instead of falling back to model memory.

Freshness and locality are both gates. If there is not enough current evidence to support the conclusion, the system should say so rather than manufacture precision.

If the seller has no asking price yet, the local range becomes the starting point. Sellumo can explain where comparable properties are positioned, which characteristics may move this property within the range, and what kind of entry position may make sense.

If the seller already has a price, the system calculates the property's €/m² position, compares it with the current local band, and classifies the asking price as below, within, or above the market. Sellumo then explains what that position may mean for demand, marketing time, value left on the table, and negotiation room.

The model's job starts after the evidence. It connects current market information with the actual property and turns the result into guidance the seller can use.

The seller journey does not happen in one chat session.

Property preparation can take days or weeks, and the questions change as the sale moves forward. The seller should not have to explain the same property, goal, or preference every time they return.

The memory architecture separates several kinds of continuity. Recent messages preserve the immediate discussion. Structured working memory keeps useful seller context such as the active property, preparation progress, missing information, selling goals, timeframe, communication preferences, and important milestones.

Semantic recall can bring relevant earlier moments back when they become useful. Observational Memory adds another layer by condensing longer conversation history into higher-value observations instead of forcing the main agent to replay every raw turn forever.

That makes the experience more continuous. Sellumo can remember what has already been answered, keep important goals in view, and adapt how it communicates without allowing memory to become another source of product truth.

A remembered preference can affect tone or level of detail. It cannot override authorization, change a property fact, or replace current market evidence.

The platform has several failure surfaces: browser errors, API failures, background delivery, performance issues, AI routing mistakes, workflow failures, and weak tool results. I built monitoring around those layers rather than relying only on application logs.

On the client side, the product captures browser failures, unhandled promise rejections, security-policy violations, page behaviour, and dead-click signals. Session replay can provide context when an issue is difficult to reproduce, while sensitive areas can be masked.

Server-side exceptions use a separate reporting path designed for short-lived serverless requests, so important failures can be captured without allowing monitoring itself to break the request. Real-user performance monitoring adds loading, responsiveness, and layout stability from production users rather than only local development speed.

The AI path has its own telemetry around routing, selected intent, route source, confidence when available, and active workflow state. If Sellumo behaves incorrectly, I can investigate whether the problem came from routing, workflow state, tool execution, or the capability that handled the request.

Background systems also keep explicit operational state. Email failure does not undo a successful message. Conversation-analysis jobs can be retried. Market research can take another current-data path. The AI has a fallback model path that can continue with the same seller memory.

Those signals are useful beyond firefighting. Repeated errors, slow paths, bad routing decisions, and AI failures become evidence for the next product or evaluation change.