In late spring 2018, we received a very interesting order to develop a web service for realtors. Back then, the brief from the client — Sergei Sergeevich Salkin, General Director of the "Ostozhenka" real estate agency — was fairly modest, and the scope of the project wasn't especially impressive. But over time we were able to grow this service from a narrow, single-purpose tool into a full-fledged platform for the community of real estate market professionals. Today we'll talk about the challenges our team faced while designing, developing, testing, and launching this project. So, here's "PUSH-KA: behind the scenes."
By the time Ostozhenka's representatives reached out to us, we had already delivered many projects with similar functionality, including CRMs and specialized business process management systems across industries as varied as retail, banking, and tobacco manufacturing. So the specifics of such products — deploying these systems, configuring them for the needs of a particular industry, and quickly adapting to market specifics — were quite familiar territory for us. That let us get started on development as quickly as possible. On the other hand, this project became valuable experience in getting into the nuances of real-estate market development: working with common feed formats (CIAN, Yandex.Realty, etc.), the timing and special settings for listing publication, unique property sales mechanics — building a tool to handle these specialized tasks turned out to be a great challenge. And we rose to it!
In late May 2018, we finalized the business description of the required service together with Ostozhenka. Even then, we and the client agreed to fully embrace an iterative-incremental approach for this project. In other words, we decided to shorten the path from the start of development to market launch as much as possible, and planned out a truly minimal MVP with the client, just enough to launch the project. Yes, even then the client already had a strategic vision for many future improvements and growth stages, but we managed to find a compromise on what could go into the MVP and what should be pushed to later stages. Jumping ahead a bit — we have to mention that working with this client on this project was a genuine pleasure! 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 say with confidence that this became a powerful driver of growth for both the client and us.
The service was originally planned to solve two key tasks. First, to significantly simplify and streamline Ostozhenka's business processes, letting them quickly and easily manage property listings across major platforms. Second, to turn this tool into an aggregator service that would let various real estate market participants solve the same tasks quickly and simply.
The MVP included only what a realtor needed to list properties on external services. Essentially, we had to build the functionality that let an agent create and save property listings in the system, and publish them across 6 major aggregator platforms. The agent needed to be able to control publication settings (which platforms a listing gets published to and which not), and the administrator needed to be able to manage publication settings for individual users. We also planned to pull the geographic name catalog system and the country's residential complex database from external sources (primarily from Yandex).
At this stage, the system had a very simple role model: the only roles were "guest" (a regular system user), "agent," and "administrator." Ostozhenka's own users were meant to become "agents," outside participants were "guests," and "administrator" was the role for managing the service. It was also planned at the time that guests would have two "subtypes" — "broker" and "owner" (for realtors and property owners, respectively). Later on, while transforming the role model, we split this into "Guest-broker" and "Guest-owner." But more on that later.
Even at the MVP stage, after digging a bit into the client's updated needs, we implemented several features that weren't in the original spec. Including:
All told, the MVP work took 3 months. Over the summer of 2018 we went from discussing business needs with the client to launching the first version of the product.
The first stage of the service's development runs from launch to roughly the end of 2018 – early 2019. At that point, the service mostly worked as a convenient tool for the client's own employees, and was only just beginning to be positioned as an external product for real estate market participants.
We once added a diagram like this to our service presentations. Later, it became the smallest thing a user could get out of PUSH-KA.RU
After launching the MVP, we immediately got to work on various quality improvements. First, we added the ability to publish to different platforms: in total, the service gained the ability to publish across 21 different platforms (including 7 large ones and 15 smaller ones).
Second, we increased the number of feed upload formats. It's no secret that there are 3 most common XML feed formats for the real estate market. In the early stages we only worked with the CIAN format; over time we managed to adapt to every format available on the market.
Publishing property listings in a feed involves a huge number of nuances. From a data architecture standpoint, a property listing is an entity with up to 50 attributes. All of these attributes need to display on the listing form in a user-friendly format, and after publication need to be not only saved to the project's database, but also added to every feed for every platform the user published to. And it's not enough to just match the required XML structure and mandatory-field requirements — the target platform's parser needs to correctly read the listing data, duplicates of previously published listings must be avoided (given that their publication IDs sometimes change due to the specifics of the business process), and photos need to be uploaded correctly (which required improving the photo handler to compress them to each platform's required format). On top of that, platforms have different requirements — certain fields are mandatory for some platforms but unnecessary for others. We had to put in considerable work optimizing the listing form and its set of attributes so that listings would publish error-free across all platforms while staying convenient for the user.
This is what the listing form looked like in the early days of the PUSH-KA.RU project
At this stage, despite our efforts to group attributes in a user-friendly way, the listing form still looked clunky and wasn't fully convenient. This was largely due to resource and timeline constraints. Later, during frontend refactoring, we revisited many of the interfaces and rebuilt this form completely, following best practices in the field (after all, we weren't the first ones to design a convenient property-listing form).
Around the same time, we managed to connect the service's first storefront, where listings published on the service were displayed publicly. Essentially, the storefront was our own alternative to an aggregator, where an outside visitor could get all the information about the listed properties. It also featured the Ostozhenka team, the services and offerings on hand, and of course the listed properties themselves. All the published listings were pulled from the main PUSH-KA service's database via a REST API.
Starting roughly in early 2019, the very positioning and business meaning of the service gradually started to shift. Where the initial focus was on solving more utilitarian tasks for the realtor ("we build a service that lets you quickly and conveniently push your listings out to a bunch of external platforms"), the vision later expanded into a universal platform for market professionals. The service went from being a "listing pusher" to a place where a realtor could log in and not only publish a listing, but also access a wide range of services — legal consultations relevant to their line of work, risk checks, ordering an extract from the Unified State Register of Real Estate (EGRN), property valuations, and many other areas. On this kind of platform, an agent also gets the ability to interact with other market participants, view property and client data in a single shared database, maintain their own database of sellers and buyers, and close deals.
Once we agreed on this new set of goals with the client, we were able to build a lot of new mechanics during the project's second stage of development.
In particular, we not only integrated a payment system into the service, but also updated the web service's structure to match the new financial model the client wanted. Now, alongside the "Tariff" entity (also known as "Partnership Format"), we introduced a "Service" entity. A single user can have only one active tariff, but several different services. Both tariffs and services can change a user's role, as well as their department assignment. We worked out logic that lets all these changes apply in the right order without conflicts, taking priorities into account (for example, access changes tied to services take priority over changes tied to tariffs). This was long, difficult work adapting the service's structure to these new realities.
For some services we built integrations with third-party services. Many of these integrations followed a similar pattern: we'd build a unique form tied to the services section, wire it up to the partner's REST API, and once the form was filled out, the request would fly off to the partner. In a number of cases, we also implemented feedback for the client — receiving status updates on their requests via that same REST connection.
We also made the tariff and service structure itself as dynamic and editable as possible through the admin panel. Essentially, we gave the client a multi-factor builder for new tariffs and services, letting them shape the financial model for user access to the service's capabilities on their own. The only cases where our help was still needed to create new services were ones requiring new partner integrations or unique, specific mechanics for new roles.
Speaking of new roles and mechanics: after learning from the client about a unique auction-sales mechanic, we were able to build not just a new service for it, but also a new role, a new listing method, and a whole package of "under the hood" changes tailored to this time-limited method of selling properties.
And finally, the most important part. We were able to build a special mechanic for the client that analyzes the database of listed properties and the database of client requests, and generates potential deals by finding properties "similar" to ones a client has already shown interest in.
Here's roughly how it works (see diagram):
What might seem like a simple scheme for finding "similar" properties and notifying agents about potential deals actually improves things significantly for realtors, saving them a huge amount of time they'd otherwise spend manually searching for matching properties. After agreeing on this scheme with the client, we implemented this mechanic in the most user-friendly format possible — agents who paid for access to the "matchmaker" could now see "potential" deals on the property page, the client page, and the property catalog page (as counters of new potential deals).
Building the matchmaker robot became one of the key innovations of the service's second development stage, and it remains one of its best features to this day.
The service's third development stage, spanning 2020–2021, can be briefly characterized by the following key features:
Let's go through the key points:
As the service developed, so did its business model. Where in the early stages users were mostly split into the client's own employees and new individual external users, the picture had now changed. The community of users working on the service came to include large groups of professionals with their own specific ways of doing business. Adapting the service to their needs required transforming how departments worked within the service — effectively creating "services within the service" for each of them. Department settings grew in number, and it became possible to configure publication settings more flexibly for different departments. The tariff options themselves started adapting to whole groups of users paying for their own space to fit their needs.
The role model on the service changed significantly too. Where once, in the early stages, we essentially had only 3 roles (for administrators, the client's employees, and external users), we now had 2 roles for new clients (owners and brokers, respectively), a separate trial role for introductory access, and a whole variety of paid roles with different capabilities. Overall, the flow of users and listings during this period grew so much that we had to significantly beef up our server capacity.
Given the growing role of new departments, the structure of the service's storefronts changed too. Where the service originally had just one storefront (essentially replacing the client's old agency website), there were now at least five storefronts, some of which were already tailored to the needs of individual autonomous departments created for agencies that had paid for "group" tariffs for working with the service.
Cashback and multi-listing mechanics were introduced. Services, which had multiplied many times over in number, were split into categories. A major new line of work emerged around foreign real estate, for which we built its own, separate listing method with a completely new set of attributes and a separate integration for displaying maps and addresses not just across Russia, but worldwide.
Finally, an ambassador mechanic appeared. Essentially, it's aimed at non-professional real estate market participants — acquaintances and other people affiliated with a realtor who bring them potential clients and get a share of the realtor's commission on the resulting deal.
The mechanic ended up working like this:
We built the whole model described above in connection with a complex structure of departments and partners. Special partner roles were created for the mechanic where curators manage ambassadors, and entire dedicated sections appeared in the service's admin panel for monitoring work with ambassadors.
As any PO knows, tight planning deadlines always mean sacrificing something for the sake of priority goals. Sometimes it's some non-critical piece of functionality, sometimes it's entire blocks of capability. In our case, for quite a long time we had to sacrifice the interface's visual polish in favor of practicality and functionality.
This is what the property view page now looks like for an agent who's paid for access to the "Matchmaker." We've of course masked the personal data in the screenshot, but that won't stop you from appreciating the functionality
Once all the main business mechanics on the service had been polished, we got down to reworking the visual side of things. We updated the property view and client view pages, and significantly reworked the listing form, bringing it closer to how similar forms look on major real estate aggregators.
Among other things, we also built a large FAQ section with user instructions, dynamically editable across a number of parameters, giving the client the ability to change its structure and content on their own (including video instructions).
We also did substantial work on the matchmaker mechanics and deal management, building a convenient mechanism for converting potential deals into real ones.
While we were changing, the major real estate aggregator platforms were changing too. Throughout the project's entire existence, our efforts to adapt listing mechanics to the platforms' constantly changing rules barely ever stopped. Given that platforms often charge the service for every "listing day" (if a property listing was live on a platform for even one day, that counts as a listing day), we had to adapt our own financial-technical model to account for listing days the same way the platforms do — especially given that a platform might check our feed 2–3 times a day, while we might update it many times over the course of a day as users make changes.
For us at Logicode, the most important thing was building the right working relationship with the client, adapting to their industry specifics. Very often, the most interesting ideas were born out of joint brainstorming sessions with the client, where long, engaging discussions produced intricate and elegant mechanics at the intersection of business logic and technical solutions. We didn't just immerse ourselves in the specifics of the real estate market — with its bulk property exports, XML feeds, and unique realtor workflows — we also had a real hand in improving practices for real estate professionals, changing their very rhythm of work and technical approaches.
Today the service keeps growing, attracting new clients and developing new services and mechanics. And we keep refining our own methodology for growing projects with an eye to industry specifics across all kinds of fields.
