Marketplace with 3 user roles: architecture breakdown using Vsedomatut

In April 2026 we launched the Vsedomatut real estate marketplace in 3 weeks. Inside — three types of accounts and an integration with Bitrix24 (a Russian CRM platform) that kept the client’s existing workflows in place. Below is a breakdown of the architecture without unnecessary theory.

What a marketplace with 3 roles is

A marketplace with 3 roles is a web product where each type of user has their own account, their own actions, and their own access level. In this kind of architecture, the storefront is not the only thing that matters — the rules do as well: who creates content, who reviews it, who sees the inquiries, and who is responsible for publishing.

For Vsedomatut, the roles split like this:

• Buyer — searches for an apartment, leaves an inquiry, saves listings of interest.
• Agent / owner — publishes listings directly and responds to inquiries.
• Partner — an external company that submits listings through a separate account with mandatory moderation.

The third role turned out to be the least standard. Without it, the project would have been a regular catalog rather than a marketplace with control over incoming content quality.

Why we needed a partner account

The client, Marat, has a pool of partner companies that supply listings. If you give them general access to the catalog, the database quickly fills with duplicates, invalid prices, outdated properties, and listings without the required data.

If you do not give them an account at all, partners start sending listing cards to a shared mailbox. Manual sorting, forwarded emails, lost comments, and a bottleneck on the team’s side follow.

Architecture — how it works technically

Three accounts do not mean three separate websites. It is one authentication system with different dashboard routes and different API permissions. Authentication in Vsedomatut is built on custom JWT — a solution without third-party services, suited to the client’s Russian infrastructure.

A user signs in, the backend checks the role, and only the actions available to that account type are returned. The buyer does not see moderation, the partner does not see other partners’ submissions, and the manager gets the tools for processing and control.

• Frontend: Next.js + TypeScript + Tailwind.
• Backend: Node.js + PostgreSQL.
• Auth: custom JWT without an external authorization platform.
• Integration: Bitrix24 API for catalog synchronization.
• Admin panel: 50+ functions — moderation, analytics, users, roles, notifications.

This approach is easier to maintain than a set of disconnected personal accounts. All the logic sits in one system, but permissions and scenarios are separated.

How permissions split between roles

The most common mistake in marketplaces is starting from screens, not from permissions. It feels like you should first design the buyer account, then the partner account, then the admin panel. In practice, it is better to start with the access matrix: who creates what, who edits what, who sees what, and who can override another user’s action.

For Vsedomatut, we split actions into several groups: viewing the catalog, creating a listing, submitting for moderation, publishing, status changes, inquiry handling, and admin actions. The buyer has minimal permissions: search, favorites, inquiry. The partner has more, but only inside their own content. The manager and administrator handle moderation, statuses, and catalog management.

This approach pays off for the business: if a new role appears tomorrow, you can add it without rewriting the whole product. For example, you can split the “moderator” role from the manager, or add a “developer” role with access only to their own properties. It stops being a chaotic set of conditions in the code and becomes a managed access model.

How listing moderation works

Moderation is not there to make the process more complex — it is there to protect the catalog’s quality. In real estate this is critical: one duplicate, an incorrect price, or an outdated status can lead to a lost inquiry and a loss of trust in the platform. That is why partner content is not published directly.

The flow is linear. The partner creates a card, fills in the property parameters, attaches images, and submits the card for review. A new publication request appears in the admin panel. The moderator sees the source, the change history, and the required fields. After review, they can accept the listing, return it for revisions, or reject it with a comment.

Importantly, the moderator’s comment goes back into the partner’s account, not lost in a chat. This reduces the volume of manual messages and creates a clear history for each listing. For the next stage, this logic can be extended: rejection reason templates, review SLAs, notifications, and analytics on the quality of incoming content.

What the Bitrix24 integration brought

Marat already had an internal system on Bitrix24 with a property database. Building a second database would have broken the team’s usual workflow. So the marketplace reads data through the Bitrix24 API and pushes inquiry statuses back.

Specifically, this solved three things:

• No need to migrate data into a separate system at launch.
• Managers kept working in the familiar Bitrix24 interface.
• The catalog on the website updates automatically rather than through manual spreadsheets.

A detailed look at the headless approach is in the article “When to move from Bitrix24 to Next.js”.

Timeline and price

Vsedomatut was launched in 3 weeks from contract to public release. The price was fixed — no hourly estimates that grow with every new clarification. The first stage included three accounts, an admin panel with moderation, the Bitrix24 API integration, basic SEO, and responsive layout.

Additional filters and extended analytics were left for the post-launch phase. That is a healthy pattern: the first version should start working, not try to cover the whole future product at once. A live look at the result is on the “Vsedomatut full case study” page, and the general service format is on the “marketplace development” page.

What to think through before development

Before building a marketplace with roles, a few questions need answers. First: who owns the data? If a partner added a property, can the manager edit its card? If the manager changed the price, should the partner see the history? If a property is unpublished, who gets a notification?

The second question is the source of truth. For Vsedomatut that source stayed inside the client’s Bitrix24 system. That kept the existing workflow intact. In another project, the source could be a CRM, a legacy ERP, PostgreSQL, or an external partner API. The main rule is to avoid two equal databases that drift apart a week after launch.

The third question is growth. The first version does not need to contain everything, but it must be extendable. If you know that two or three months in there will be new partners, new statuses, and separate reports, that should be built into the role and API structure from day one. That way the first launch stays fast, and the second stage is not a rebuild from scratch.

Why this is not just a “personal account”

The personal account is often perceived as a profile page with a list of inquiries. In a marketplace, the account is part of the business process. It defines how content enters the system, who is responsible for quality, how inquiries flow through the team, and where delays appear.

That is why in such projects scenarios matter more than screen count. One well-designed moderation screen can save more time than ten beautiful but useless widgets. For the client, this comes down to a simple thing: the team handles fewer manual messages and brings a listing to publication faster.

That is the whole point of an architecture with 3 roles: it turns a website from a storefront into a working system. The buyer sees a clean catalog, the partner understands the status of their listings, the admin controls quality, and the business owner has a manageable growth model.

What metrics the owner should watch

After launching a marketplace with roles, watching only traffic and inquiries is not enough. These metrics show the surface but do not explain where the process breaks. A platform with partners needs separate indicators per role: how many properties partners add, how many go for revisions, how many are published, how many inquiries arrive on partner properties, and how long moderation takes.

If partners are actively adding listings but most are rejected, the issue is not in advertising — it is in the quality of incoming content or in the submission form. If listings publish quickly but get no inquiries, look at the card, filters, and search results. If inquiries come in but managers reply late, the bottleneck is in the operations team.

That is why marketplace analytics has to be tied to roles. Standard web analytics answers the question “how many people came in.” Role-based analytics answers a more useful one: “which part of the system creates or loses value.”

Why the admin panel matters more than it seems

On the public side, the user sees the catalog, listing cards, and forms. But the business lives in the admin panel every day. If the admin panel is awkward, the team starts working around it through spreadsheets, chats, and manual notes. A month in, the owner no longer knows where the up-to-date information is.

Vsedomatut’s admin panel includes 50+ functions: managing listings, users, roles, moderation, inquiries, notifications, and analytics. This is not “internal plumbing” — it is the team’s workplace. That is where the path from a partner submission to a published listing is decided.

A good admin panel reduces support cost. If the manager can change a status, reject a card, view the source, and check history themselves, the developer is not pulled in for every operational task. For a marketplace, this is one of the main payback factors.

When this architecture suits your business

A marketplace with 3 roles makes sense when content is created by more than just your team. If suppliers, agents, partners, or merchants need to add data themselves, a system without roles quickly turns into manual operational chaos.

• You have a pool of external content suppliers: partners, agents, merchants.
• Content needs to be moderated before publication.
• Buyers need to interact with suppliers directly.
• You already have a CRM or another source-of-truth system you do not want to break.
• You need analytics per role separately.

If at least three of these match, role-based architecture usually pays off: less manual work, fewer errors, and clearer ownership inside the product.

FAQ

How much does a marketplace with 3 user roles cost?

It depends on the number of integrations and logic complexity. A baseline version with three accounts and an admin panel starts from $4,500 — fixed price, 3 to 4 weeks of work. Final pricing is set after a short brief.

Can we start with two roles and add a third one later?

Yes. The architecture is built with role expansion in mind from day one. Adding a new role later is a separate task that usually takes 5 to 10 days.

Is the Bitrix24 integration mandatory?

No. Marat had Bitrix24, so we integrated with it. If you have a different CRM, an inventory system, or nothing at all, the architecture stays the same — only the data source changes.

Who moderates partner listings?

Any user with moderator permissions in the admin panel. For Marat, this is a team of two: they see incoming listings and review submissions during the day.

Can we launch a marketplace without our own developers?

Yes. After launch we hand over full code and infrastructure access. From there you can work with any contractor or grow the product with your own team.

Want a marketplace like this?

If you want to compare it with a simpler format, take a look at “How much a landing page costs and what you actually pay for”. For a deeper take on the stack, the article “When to move from Bitrix24 to Next.js” is useful. Other materials are in the blog index.