Alemica: building a multi-market real estate platform from zero
Role:
Product Designer
Team:
PM, 2 analysts, 4 engineers
Timeline:
MVP in 6 months, 2024–2025
Markets:
KZ + UZ/AZ
My scope:
UXR, product design, design system
A major property developer was expanding into new markets with no broker-facing tool to support growth. We replaced a single-market legacy platform with one product built for three countries and took it from strategy to launch in six months.
Platform interface, UI shown in Russian
At a glance
Problem. A single-market legacy platform was holding back expansion into two new markets.
Approach. A research sprint and an audit of the old platform surfaced four recurring symptoms. We kept the core flow, improved every stage, and shipped a multi-market MVP in six months.
Result.
−35%
Transaction time
~ −20%
Support tickets
+18%
Funnel conversion
0.34 → 0.41
DAU/MAU
PROBLEM
The developer’s subsidiary managed broker relationships on an internal platform called RBD. It was built for a single market, carried significant UX and visual debt, and contained unnecessary steps in several key scenarios.
When the business began expanding into Uzbekistan and Azerbaijan, we had to decide: iterate on RBD or build something new. We chose to build new. RBD lacked the architectural flexibility for multi-market support, and the accumulated technical and UX debt made iteration too expensive at the pace the business needed.
“We were losing potential brokers from Uzbekistan simply because we had nothing to offer them. The demand was there, the clients were there. The platform wasn’t.”
- Head of Product, project kickoff brief
STRATEGY
Understand where we’re going before designing anything
Before the first wireframe, we ran a three-week research sprint. Analysts covered market and competitive analysis. I owned the user side: interviews, behavioral patterns, and expectations around digital tools.
1
Competitive landscape (led by analysts).
Kazakhstan had established players, while Uzbekistan and Azerbaijan had weak competition and brokers worked without dedicated tools. This confirmed the timing was right.
2
14 in-depth interviews with brokers (led by me).
4–6 per country, focused on how a typical workday is structured, where friction occurs when closing a deal, and what prevents brokers from working with cross-border listings. Key insight: brokers weren’t operating locally by choice. They lacked the infrastructure of trust and the tooling to go international.
3
RBD audit (with analysts).
We walked through the entire RBD scenario end to end and documented every step. The audit surfaced four recurring symptoms, and they became the lens for everything that followed:
Too many steps. Some were outdated, and some split one logical action across several screens. This slowed every deal.
Unclear forms and statuses. Fields went unused downstream, and deal status was hard to read. Brokers had to ask for help.
Friction at key funnel stages. Reservation, for example, happened without a visual floor plan, so brokers dropped out mid-flow.
No reason to come back. Commission was calculated separately, and there was no view of performance.
4
MVP scope (with the PM and business stakeholders).
A value/effort prioritization session led to one decision: the MVP covers the full core transaction flow, and everything else goes on the roadmap. That let us ship in 6 months without cutting corners on the critical path.
KEY DECISIONS
Hard trade-offs — not just good screens
Three decisions shaped the product most, each with real arguments on both sides.
1. Preserve the core flow from RBD instead of reinventing it
The instinct was to rethink the broker journey entirely. Research said otherwise: search → client registration → reservation → deal → payout was deeply ingrained for Kazakh brokers, and relearning it would create friction during migration.
Decision: keep the structure, improve each stage individually. This is why the work targeted the four symptoms stage by stage rather than redrawing the journey.
2. One unified interface for all markets instead of localized versions
Markets differ in property types, legal stages, and currencies.
Decision: one platform with market-configurable parameters. It made every screen harder to design, since each had to be validated against scenarios from all three markets, but it lets us add new markets without rebuilding the product.
3. Defer advanced analytics to the second release
Brokers asked for detailed analytics. Building them into the MVP would have pushed the launch back by 2–3 months.
Decision: ship a basic dashboard and a leaderboard in v1, and bring fuller analytics in later releases. It was a difficult call, since several interviewees flagged analytics as important, but it let us launch on time without compromising the core flow.
DESIGN
Same flow, less friction at every stage
The core journey was preserved. The work happened inside each stage, and each change was aimed at one of the four symptoms from the audit.
Greater focus on floor plans for comparison + the start of the reservation/transaction/booking process is always on-screen
Design system. In parallel with the screens, I built the design system: components, tokens, and interaction states. Engineers moved faster, and 40+ screens were added without visual drift from what was already shipped.
VALIDATION
Every functional block went through a usability test before handoff. We tested with brokers from the target markets, separately for KZ and for UZ/AZ, since usage scenarios differed by country. In the tests, the core scenario was completed ~28% faster than in RBD.
What we changed as a result:
Redesigned the hierarchy on the reservation screen, since users missed the confirmation button.
Added a deal progress indicator after 3 of 5 participants couldn’t tell which step they were on.
Removed 4 fields from the client registration form.
Clarified status labels: “Under review” → “Awaiting signature”.
OUTCOMES
Launch is the beginning, not the end
The MVP shipped to production 6 months after kickoff, on schedule. Kazakhstan is live, and Uzbekistan and Azerbaijan are onboarding. After launch in Kazakhstan, the four symptoms from the audit moved:
−35%
Average transaction time
PROBLEM
Too many steps
Outdated steps removed, shorter registration, status readable from the first screen. Usability tests predicted ~28% faster.
~ −20%
Flow-related support tickets
PROBLEM
Unclear forms and statuses
Unused fields removed, clearer status labels, progress indicator.
+18%
Funnel conversion
PROBLEM
Friction at key stages
Floor plan selection inside reservation, shorter form, clearer confirmation screen.
0.34 → 0.41
DAU/MAU stickiness
PROBLEM
No reason to come back
Leaderboard, commission analytics, transparent payouts, across a sequence of releases.
These are team results. My part was the research that identified the symptoms, the flow and interaction design that addressed them, the usability testing that tuned the solution before launch, and the design system that let us ship it consistently.
REFLECTION
What I’d do differently
The 6-month deadline meant deliberate trade-offs. The clearest one was the design system: I built the components and tokens the MVP needed, but documentation (usage rules, states, edge cases) went to the backlog. After launch the team’s focus moved to onboarding new markets, and the documentation was never fully written. As a result, new screens depend more on knowing how components were meant to be used than on a guide anyone on the team can follow.
If I did this again, I would agree on a known-debt list with the PM before launch, with owners and dates, and document each component as it ships rather than after. I would also set up usage tracking from day one, so we could judge what brokers actually value rather than relying on interviews alone.
