# Domora: a two-surface operating system for real-estate brokerages > A brokerage keeps two clocks. One runs in public, where properties are presented and interest begins. The other runs in private, where inventory changes, demand is interpreted, visits happen, opportunities advance, commissions are tracked and owners ask what the business is doing. Source: https://saascode.ai/inside/domora-two-surface-brokerage-operating-system · Published: 2026-09-01 · Section: builds · Product: Domora (https://saascode.ai/products/domora) --- A brokerage keeps two clocks. One runs in public, where properties are presented and interest begins. The other runs in private, where inventory changes, demand is interpreted, visits happen, opportunities advance, commissions are tracked and owners ask what the business is doing. The clocks describe one business, but software often treats them as unrelated rooms. Domora is organized around the decision to connect them. Its public surface is an image-led property portal on the brokerage's verified domain. Its private surface is a workspace for inventory, contacts, demand, visits, opportunities, agents, commissions, publication, owner reporting and analytics. The product is multi-tenant, so the same operating system can serve multiple brokerages while each brokerage receives its own connected pair of surfaces. That is the whole documented premise. It is enough to reveal a useful product-design problem: a real-estate platform is not simply a website with an admin panel, and it is not simply a CRM with a public landing page attached. The public and private sides carry different audiences, rhythms and responsibilities, yet they need a shared model of the business. ## The public portal is an operating boundary An image-led property portal has an obvious visual job. It presents inventory in the register that property decisions require. Photography, context and the ability to move through available properties shape the public experience. But the more important boundary is organizational. The portal is where a brokerage chooses what the market can see, under the brokerage's own verified domain. That domain matters because a brokerage's public identity should not disappear behind the software operator's identity. A multi-tenant product can still give each customer a distinct public presence. The operator runs the service, while the brokerage presents its inventory through a domain it has verified. Public presentation and tenant identity therefore meet at a concrete boundary rather than at an abstract branding setting. Publication connects that boundary to the private workspace. Inventory is not merely stored; it has a relationship to what becomes public. The documented facts do not specify syndication, feed providers, search behavior or publishing automation, so none can be inferred. The structural point remains: publication belongs in the same system that understands the inventory being published. ## The private workspace needs more than contacts Calling the private side a CRM would hide much of its stated scope. Contacts are present, but so are demand, visits and opportunities. Those nouns describe different stages of commercial understanding. A person exists as a contact. What that person is seeking can be represented as demand. A visit records a meaningful interaction with a property. An opportunity gives active work a commercial shape. The distinction is useful because real-estate activity is not reducible to a single linear pipeline. Inventory has its own state. People have requirements that may not map cleanly to one property. Visits connect people and places in time. Opportunities gather the work that may result from those connections. Treating each as a separate concern allows the product to represent the brokerage's work without making every event a note on a contact record. Agents and commissions extend the model beyond customer relationship management. The brokerage is not only following demand; it is coordinating people who perform the work and tracking the commercial consequence of that work. Owner reporting and analytics then create a management surface above the day-to-day records. They make the private workspace relevant to brokerage leadership as well as to the people handling inventory and opportunities. No exact workflow, report count or calculation method is part of the current product facts. The value of the model does not depend on inventing them. The documented scope already shows the intended span: from inventory and market-facing publication through commercial activity to agent participation, commissions and owner visibility. ## Why the connection carries the product Separating a property website from internal operations creates a recurring translation problem. The public system knows what it displayed. The private system knows what staff entered. Another layer has to reconcile identity, inventory and activity between them. Even when that reconciliation is technically possible, it becomes a continuing product responsibility. Domora's two-surface definition makes the connection primary. The portal and workspace are not presented as independent tools in a bundle. They are the two sides each brokerage receives. That wording changes the architecture of the business proposition: the operator offers a brokerage environment, not a collection of unrelated subscriptions. The public side can remain focused on presentation because the private side carries operational complexity. The private side can remain focused on the brokerage because publication has a defined destination. Each surface can speak to its audience without pretending the other audience does not exist. This also explains why multi-tenancy is central rather than incidental. If the product served only one brokerage, the connection could still be useful, but it would be a custom internal system. Serving multiple brokerages turns the same structure into a vertical SaaS. Each customer needs a public identity and a private operating context, while the product operator needs a repeatable service that preserves those customer boundaries. ## The owner is a distinct user of the system Owner reporting appears late in many software descriptions, after the operational modules have been listed. In the Domora definition it helps complete the loop. A brokerage owner does not need only a larger version of an agent's task list. Ownership asks different questions: what inventory is active, what demand exists, which visits and opportunities are moving, how agents participate, what commissions are attached, and what the overall activity suggests. Analytics sits beside reporting in the documented scope. The distinction can be kept qualitative. Reporting presents the state of the business; analytics helps inspect it. The facts do not define dashboards, formulas or predictive features, so the product story should not pretend they do. What matters is that management visibility is part of the private workspace rather than a separate afterthought. That placement has a product consequence. The same system that presents inventory publicly and records operating work privately can also support the brokerage's management view. The owner does not have to understand the product as two disconnected investments—one for acquiring attention and another for supervising operations. ## Source ownership changes the road after launch Domora is offered as a source-code product for an operator to deploy under its own brand. That acquisition model does not eliminate operating work. It relocates it. Hosting, customer acquisition, onboarding, support, local integrations and ongoing product choices belong to the business running the SaaS rather than to a managed-software vendor. The trade is control for responsibility. The operator can shape the product around a market, a brokerage type or a client engagement. It can choose how the service is branded and how it evolves. It must also maintain a dependable deployment and decide which surrounding services the target market requires. Source ownership is not a shortcut around product operations; it is the ability to make those operations part of the operator's own business. The model should not be confused with source redistribution. The product is for customization, deployment and operation, including a service run for paying end users or a product delivered to a client. The underlying source package is not positioned as inventory to resell. That distinction keeps the acquisition aligned with the business Domora is meant to enable. ## What the documented scope leaves open The catalog record names no technology stack, MLS or IDX provider, communications suite, payment layer, infrastructure model, mobile application, AI capability, integration catalog, onboarding service or support commitment. It includes no feature list, technical specifications or screenshot captions. Those gaps are not invitations to complete the story from memory or from an internal plan. They are instead a useful boundary around this account of the product. Domora can be described confidently as a multi-tenant operating system with a public portal and a private workspace spanning the stated brokerage concerns. Anything more specific belongs to a later catalog fact, a documented product update or a market-specific implementation. The road described here ends at a product definition and a reviewable demo. What it deliberately does not do is turn a build narrative into a capability claim: what Domora does is established by the demo, not by this story. ## One business, seen from both sides The enduring idea in Domora is not a long list of modules. It is the relationship between the brokerage's public promise and its private work. Inventory crosses that relationship through publication. Contacts and demand give public interest an internal form. Visits and opportunities carry the commercial process. Agents, commissions, reporting and analytics connect execution to ownership. A two-surface system makes those relationships part of the product rather than leaving them to a future integration project. The portal can remain recognizably public, the workspace recognizably private, and the brokerage recognizably itself through its verified domain. Multi-tenancy then turns that paired structure into a service an operator can run for more than one brokerage. Domora's documented scope is deliberately legible at that level. It says what the product is without requiring fabricated metrics, invented integrations or an undocumented engineering chronology. For a vertical SaaS, that clarity is a practical foundation: the market, the operator, the brokerage and the brokerage's customers each occupy a different place, and the product has a surface for the places that need one. [See Domora →](https://domora.saascode.ai) ## Related reading - [Domora vs BoldTrail: source ownership or a managed brokerage ecosystem?](https://saascode.ai/inside/domora-vs-boldtrail.md) - [Six real-estate brokerage platforms for six different acquisition decisions](https://saascode.ai/inside/real-estate-brokerage-platforms.md)