I am Rashed Hareb Al Mheiri. I chose infrastructure, which built trust

Rashed Hareb Al Mheiri does not talk about traction as if it settles the argument. The more revealing milestone at Rentify, he suggests, was simpler and harder to fake: seeing the system work exactly as intended in the real world. A tenant opted for flexibility. A landlord was paid upfront and on time. The full cycle completed digitally, without friction, and both sides trusted it.

That mattered more than any early growth figure because it proved something operational, not just commercial. In a business sitting between property and finance, the real test is not whether people like the idea. It is whether the model can carry different incentives, different anxieties and different definitions of risk, all at once.

When asked about the moment that stood out most, Al Mheiri returns to execution rather than scale. Rentify had already crossed meaningful milestones on paper, but he is clear that signed value, take rates and onboarding numbers were never the whole story. The real breakthrough came when the product stopped being a pitch and became behaviour.

That distinction says a lot about how he thinks. In categories where trust is the product, metrics can flatter before the operating model is truly tested. What convinced him was not demand in the abstract, but a complete payment flow working cleanly for everyone involved.

On the question of early adoption, Al Mheiri frames the challenge as one of synchronising three different risk cultures. Landlords wanted certainty, in the most literal sense. Their concern was straightforward: will I get paid on time, every time? They were used to cheques and upfront payments, so any change to that habit had to feel at least as reliable as the old system.

Banks looked at the same model through a different lens. For them, the conversation was about underwriting, defaults, compliance and whether the structure made sense within regulatory boundaries. Opportunity alone was not enough. They needed evidence before conviction.

Tenants sat between those positions. They wanted flexibility, but were wary of anything that looked like hidden debt or an extra burden dressed up as convenience.

The difficulty, then, was not messaging. It was credibility. Rentify had to persuade all three sides at once, before it had the historical data that would normally make the case easier.

Pressed on what counts as Rentify's biggest success so far, Al Mheiri points to market adoption at scale, not simply the headline figure of 1.5 billion AED in signed property value. Plenty of businesses can announce partnerships or pipeline. The harder part is converting that into regular usage and real transactions across both landlords and tenants.

He attributes that outcome to two things, pricing and execution. Rentify made the product easy to adopt without damaging landlords' economics or putting too much cost on tenants. Just as importantly, the company treated the experience itself as part of the proposition. Onboarding, payments and communication had to feel simple and dependable.

There is a useful discipline in that framing. He does not describe adoption as the result of branding or momentum. He describes it as the result of removing reasons not to use the product.

When the conversation turns to product design, Al Mheiri makes a point that is easy to say and difficult to operationalise: simplicity at the surface usually means complexity underneath. In his view, Rentify is not one product but a structure aligning two very different users.

For landlords, the priority is certainty. For tenants, it is flexibility and transparency. The only way both groups can experience the product as intuitive is if the business absorbs the underlying complexity itself, through structuring, pricing and technology.

That is a useful corrective to the usual talk about seamless experiences. Seamlessness is not a design flourish here. It is the result of carefully deciding which complexity the company should carry so that customers do not have to.

Asked to reflect on day-to-day leadership, Al Mheiri comes back to clarity and trust. In a regulated environment, he argues, people need to understand both the objective and the non-negotiables. Ambiguity around either one slows teams down or creates unnecessary risk.

His answer is to build systems rather than rely on constant supervision. Strong processes, clear ownership and good communication are what allow a team to move quickly without becoming careless. He is explicit about the trade-off: speed matters, but not at the cost of reliability. In a trust-driven business, reliability is not a support function. It is the core of the offer.

When asked about failure, Al Mheiri does not reach for a dramatic story. He points to a more common and more damaging operator error, pushing growth before the foundations were properly validated. The cost was time and capital, but he places greater emphasis on what it revealed: how quickly a business becomes inefficient when the model is not solid.

That lesson still shapes how he operates. At Rentify, he says, the company still moves fast, but with more discipline around validation, economics and sequencing. The balance he is after is not caution for its own sake. It is speed with structure.

He extends the same point when discussing the worst decision of his earlier career. In a previous business, he expanded too aggressively into markets that looked attractive on paper but lacked the customer purchasing power to sustain the model. Franchising into multiple countries created footprint, but not necessarily viable unit economics. His conclusion now is straightforward: depth over breadth, and real demand over perceived opportunity.

On the question of the best decision he has made, Al Mheiri's answer is strategically revealing. He chose to build Rentify as infrastructure rather than as a purely consumer-facing product. At the time, he says, that was not the obvious path. A direct consumer play may have offered faster short-term growth.

But he believed the larger opportunity was to become the layer connecting landlords, tenants and financial institutions. That choice mattered because it shifted the company from chasing attention to embedding itself in the system. In his telling, that creates stronger partnerships, a more defensible position and a clearer route to long-term scale.

It is also consistent with everything else he says. If your market is defined by trust, then becoming part of the underlying mechanism can matter more than becoming visible.

When the conversation turns to hiring, Al Mheiri is notably unsentimental. He looks first for ownership, clear thinking and the ability to operate without constant direction. In an early-stage business, he suggests, that combination matters more than polished credentials.

The red flags are equally practical: weak accountability, poor communication and an inability to make decisions in uncertain conditions. His test for capability is simple enough to be useful. Give someone a real problem with minimal guidance, then watch how they think, whether they take ownership, and whether they can move the work forward.

This is the logic of an operator who values self-direction over performance in managed environments. Early-stage companies do not just need talent. They need people who can function before everything is clear.

Asked what advice he would give someone entering fintech or proptech in the UAE, Al Mheiri does not begin with fundraising, networking or product. He starts with proximity to the problem. Spend time with landlords, tenants and banks. Learn how things work in practice. Validate assumptions early, before trying to scale.

The habits that keep him effective are similarly plainspoken: focus on what actually moves the business, stay close to the numbers and execute consistently week to week. In his view, clarity and consistency beat scattered effort.

That answer lands because it echoes the rest of the conversation. Across product, leadership, hiring and expansion, Al Mheiri keeps returning to the same operating belief: do not confuse movement with proof. Build something that works in the system you are actually serving, then scale from there.