HomeCasesPUSH-KA Real Estate Marketplace Development

Development of PUSH-KA Real Estate Marketplace

Type:Web Portal
Audience:B2B, B2C
Tech Stack:PHP, Yii2, Docker, Docker Compose, GitLab
Client:Ostogenka Real Estate Agency

Development

Task:

Create a comprehensive web service for automating the listing and promotion of commercial and residential real estate across dozens of platforms, as well as managing leads and enabling effective collaboration among real estate market professionals.

Solution:

A multifunctional web marketplace was developed with CRM integration, an automated listing syndication system, a personal account with a wide range of tools including auction mechanics and a cashback service. A communication platform was built for the professional real estate community — the PUSH-KA marketplace.

Description

In late spring 2018, we received a very interesting commission to develop a web service for real estate agents. The client brief — from the CEO of the Ostogenka real estate agency, Sergey Salkin — was quite modest at the time, and the project's scope wasn't particularly impressive. However, we were later able to evolve this service from a narrow tool into a full-fledged platform for the professional real estate market community. Today we share the challenges our team faced during the design, development, testing, and launch of this project. So: "PUSH-KA: Behind the Scenes".

By the time Ostogenka's representatives reached out to us, we had already delivered numerous projects with similar functionality, including CRM systems and specialized business process management systems for a wide range of industries — from retail and banking to the tobacco industry. So we were familiar with the specifics of such products: deploying and configuring these systems to meet industry requirements, and adapting them quickly to market conditions. This meant we could kick off development very promptly. On the other hand, this project gave us valuable experience diving into the nuances of real estate development: working with widely-used listing feed formats (CIAN, Yandex.Real Estate, etc.), the periodicity and special publication settings for real estate listings, unique property sales mechanics. Developing a tool to address these specialized challenges was a great opportunity for us — and we delivered!

From the very start, we aligned with the client on fully embracing an iterative-incremental development approach. In other words, we decided to minimize the path from the start of development to market launch, and planned together an extremely lean MVP — just enough to get the project off the ground. Even then, the client had a strategic vision of many future improvements and development phases, but we found a compromise on what should go into the MVP and what could wait for later stages. Looking ahead, we can't help but mention — working with this client was genuinely comfortable! Over time, we adapted more and more to the specifics of the real estate market, and the client adapted more and more to the rhythm and nuances of web development. We can confidently say that for both the client and our team, this became a powerful growth driver.

Initially, the service was planned to address two key goals. First, to significantly simplify and optimize Ostogenka's business processes, enabling quick and hassle-free management of real estate listing publications across key platforms. Second, to turn this tool into a service aggregator, allowing various real estate market participants to quickly and easily accomplish the same tasks.

First Steps: MVP

The MVP included only what a real estate agent needed to list properties on external services. Essentially, we had to develop functionality allowing agents to create and store real estate listings in the system, and publish them across 6 major aggregator platforms. Agents were to be able to manage publication settings (which platforms to publish on and which not), while an administrator could manage publication settings for individual users.

It was assumed that the geographic catalog system, as well as the residential complex database, would be sourced from external providers (primarily Yandex).

"Agents" would be Ostogenka users, "guests" — external participants, and "Administrators" — the management role. At the time, guests were planned to have two subtypes — "broker" and "owner" (for real estate agents and property owners respectively). Later, as we transformed the role model, we split this into "Guest-Broker" and "Guest-Owner". But more on that later.

Even at the MVP stage, after delving deeper into the client's updated requirements, we implemented several features not in the original specification.

Including: • We built client base functionality for users. Our agent-users gained the ability to add clients to their database and link them to properties they are interested in. • We added subdivision management. After learning about the client's business structure, we introduced the ability to assign registered users to specific subdivisions and to tie certain rights and permissions to subdivisions. Some rights were role-based, others subdivision-based — we did significant work to ensure rights for roles and subdivisions worked harmoniously, without duplication and while addressing different business logic tasks. Using this functionality, the client was able to create subdivisions for both external users and internal staff, configuring access in the most convenient way for business needs. • We added a dedicated feed management section • We enabled the client's staff to manually update residential complex data • We built a reference library where client-uploaded documents required by agents are stored hierarchically

The MVP work took 3 months in total. During the summer of 2018, we went from discussing business needs to launching the first version of the product.

Submit a request