One platform, four sides
A property marketplace that brings brokers, borrowers, lenders and verification vendors onto a single system. Brokers post and publish listings, vendors run paid verification work, and role-based access keeps every side to its own surface.
Sector
- Real estate
- Property marketplace
Roles
- Broker · Borrower · Lender
- Vendor · Agent · Employee
Surfaces
- Broker workspace
- Vendor portal
- Lender onboarding
What we did
- Product modelling
- UX + UI design
- Front-end build
What problem does it solve?
Listing a property is only the first step. Getting it verified, paid for and published pulls in a broker, the agents under them, the borrower behind the deal, a lender and an independent verification vendor - and each of them needs to act without seeing everyone else's business.
Four parties, one system, fenced-off surfaces
Real Port models the whole marketplace rather than a single dashboard. The broker workspace is the command centre for listings, people and payments; the verification vendor gets a portal for proposals and reports; the lender gets a fenced onboarding path. Role-based permissions decide who can do what, per role and per member.
Why does a property marketplace resist ordinary listing software?
Three things separate a marketplace from a listings site, and none of them are solved by a nicer property card: the sides must stay separated, verification is real paid work with its own lifecycle, and publishing has to gate on both money and a report.
What does the product actually contain?
The walkthrough runs a listing from the broker workspace through payment and verification to a vendor's report, then opens the surfaces the other sides work in.
Properties & listings
CoreThe heart of the broker workspace: a property portfolio and a detail view broken into tasks, property info, statistics, a document data room, financials and highlights & amenities.
- Data room
- Financials
- Amenities
Post, pay & go live
3 stagesA post-a-property flow, a make-payment-and-publish step and a property-go-live payment - the paid path from draft to public listing.
- Post property
- Make payment
- Go live
Verification
Full lifecycleA verification work fee, a vendor report upload with draft and submit states, and a broker work-review step that can approve or reject and request a resubmission.
- Work fee
- Report upload
- Work review
People & permissions
RBACManage borrowers and their requests, manage and invite agents, and a roles-and-permissions module that activates members and scopes what each one can reach.
- Borrowers
- Agents
- Roles
Vendor proposals
4 statesSubmit, update and withdraw proposals, a proposal detail view, and payout reporting - the vendor's workflow for winning and being paid for verification work.
- Proposals
- Payouts
Account & comms
SharedAn inbox, notifications, payment methods, account settings, change-password and help & support - the account plumbing shared across every role.
- Inbox
- Payment methods
- Settings
How did we build it?
A marketplace is only trustworthy if each side is confident the others cannot overreach. That constraint drove the order of the work more than any single feature did.
Three surfaces, built for three different jobs
The platform serves six roles, but three of them get a dedicated app surface designed around what they actually do. Switch between them - the workspace changes, and so does what each side is allowed to reach.
- Post, edit and publish properties
- Manage borrowers, agents and their invitations
- Set roles and permissions for the team
- Pay verification and go-live fees
What does a multi-sided property marketplace need?
Six rules came out of building this one, and they hold for any marketplace where several parties act on the same asset from different sides.
- Give every side its own surface. A broker, a vendor and a lender doing their job in one undifferentiated dashboard is how a marketplace becomes a spreadsheet with a login.
- Make permissions granular and reversible. Adding a team member should grant a scoped role, not a copy of the account - and it should be one toggle to switch off.
- Treat verification as a job with a lifecycle. A proposal, a fee, a report and a review are distinct states; collapsing them into an attachment loses the audit trail.
- Gate publishing on money and proof. If posting and going live are the same action, the marketplace fills with unverified, unpaid listings.
- Keep the record as the source of truth. Financials, documents and statistics belong on the property, not in the messages about the property.
- Share the plumbing, not the data. Inbox, notifications, payments and settings can be common code; what each role sees inside them cannot.
Building a property marketplace platform
The questions brokerages and proptech founders ask us first, answered plainly.
Ask us yoursHow long does it take to build a property marketplace platform?
A first release at this scope - several roles, a broker workspace, paid publishing and a verification lifecycle - is a matter of months rather than weeks. What moves the date most is the number of distinct roles and how strict the separation between them has to be, since the permission model touches every screen. We phase it so the broker workspace ships before the fenced vendor and lender surfaces.
How do you keep brokers, lenders and vendors separated?
Through role-based access designed before the screens were. Each role gets a surface built for its job and a permission set that scopes what it can reach, and team members are activated and toggled individually rather than inheriting the whole account. The separation is a data-model decision, not a UI one, which is why it holds as the product grows.
Can it handle paid listings and verification fees?
Yes - that is central to the design. Posting a property is free, but publishing it runs through a make-payment step, and engaging an independent verification vendor runs through a separate work fee, each with saved-card, add-card and error states. Payment is treated as a gate on going live, not an afterthought.
How much does a platform like this cost?
It depends on scope, and an honest quote needs more than a feature list. The biggest drivers are the number of roles and separate surfaces, whether payments and payouts are in scope, and how much of the verification workflow is automated. Shanti Infosoft scopes it on a short call and returns a fixed quote within 48 hours.
Can it be extended to more roles or regions later?
That is the reason for modelling roles up front. Because access is defined per role against a shared data model, adding a role or a surface later is an extension of the permission model rather than a rebuild. The account plumbing - inbox, notifications, payments, settings - is shared, so new roles reuse it.
Related work
Building a marketplace with more than one kind of user?
Tell us how your business actually works and we will tell you honestly what it takes to build. See more of our work or what we do.
Book a 15-minute call