How We Helped a Proptech Platform Retain Its Biggest Client

A Middle Eastern proptech company was facing a major crisis. The CTO was leaving, and their product—a platform managing rents, billing, and service charges across hundreds of properties—suffered from constant outages. Additionally, financial audits that should have been closed by February were dragging into September, exposing the company to regulatory fines. As a result of these mounting issues, their biggest client (a large property management firm serving tens of thousands of tenants) was losing patience and threatening to leave.

On the surface, the problems looked distinct: a departing CTO, regular outages, missed deadlines, and a team without processes. However, they all stemmed from one systemic issue. The entire engineering department had relied solely on one person. No one had built the processes, standards, or leadership structure to sustain the team after the CTO’s departure. This wasn’t the fault of a single person. The entire management culture had failed, operating on avoiding difficult decisions and forcing results through pressure.

A former client of ours, Kitopi, referred the company’s CEO to Pragmatic Coders. We talked on Wednesday. By Saturday, we were on a plane to the Middle East for on-site workshops. What we found was more serious than expected.

Challenges

On The Client’s Side

The CTO’s departure didn’t cause these problems. It exposed years of structural dysfunction that his presence had masked. The company had operated with one person absorbing every technical decision. Once he was gone, the gaps became visible:

• No processes. No ticket system, no requirements documentation, no structured communication between engineering and the business. Tasks were literally assigned as comments in the source code. A year after the CTO’s departure, we were still finding his annotations in the codebase telling developers what to do and where.
• Requirements mess. There was no discovery process. Requirements were often arbitrary and disconnected from what users actually needed. Users didn’t engage with large parts of the application because the UX was too complex to navigate. Complexity had accumulated in areas where simplification was both possible and necessary.
• System instability. Full application outages happened regularly. The entire system would go down, disrupting operations across multiple properties and thousands of end users.
• Regulatory and investor pressure. Audit delays, regular outages, and the CTO’s departure created a perfect storm. The company’s investors demanded immediate platform stability and a return to compliant reporting.
• Lost institutional knowledge. High turnover in prior years meant much of the codebase had been written by developers who no longer worked at the company. The remaining team had been there for one to two years on average. Tribal knowledge was gone, carried away by people who had moved on.

On Our Side

What we found on the ground was worse than the brief suggested. We spent a week in on-site workshops with two developers and the outgoing CTO. The system had far more functionality than anyone had communicated upfront. The client’s own developers regularly disagreed about how specific features were supposed to work.

• No automated tests. The client’s team had previously attempted to introduce them, but it was done improperly and ultimately never took hold.
• No documentation. Someone had tried generating docs with early AI tools, producing a 70-page PDF that was effectively unreadable.
• Unreadable codebase. Shaped by the turnover described above, with no way to understand the reasoning behind past decisions.
• Junior team. Most developers had three to four years of experience. The most senior members were senior in domain knowledge, not engineering practices.
• Cultural friction. The team was accustomed to a top-down model where the CTO told them what to build and how. We needed them to take ownership. From their perspective, we were the rigid outsiders insisting on unfamiliar structure. From ours, the team wasn’t used to process discipline. This wasn’t resistance in the usual sense. It was a genuine gap between working cultures that took real negotiation on both sides. The shift happened, and it happened relatively quickly. But calling it one-sided wouldn’t be honest.
• Technical resistance. Some developers believed the system was fundamentally sound and just needed its bug backlog cleared. As one put it: “We have a good car. It just doesn’t work right now.” We saw it differently, but we had to earn trust before we could change minds.

Our Approach

We moved on both fronts at once: stabilizing the platform and overhauling how the team worked. We implemented a process close to our standard one, worked through early friction with the team, and it took hold relatively quickly.

• First few months: We eliminated the full outages and got audits back on track. Developers moved from executing tasks handed down by the CTO to actively engaging with the business on requirements and technical decisions.
• Three to four months in: We had enough understanding of the system to recommend a major refactoring of the codebase. The client wasn’t ready for that investment yet. So we focused on what we could control. All new code followed proper engineering standards. We also cleaned one foundational area of the system and made it a reference point. We wrote automation tests against it and used it to validate business logic. The legacy code remained, but the accumulation of new problems stopped.
• About a year in: One of our consultants transitioned into a hands-on engineering leadership role within the client’s organization. That role evolved into a full head of engineering position.
• After two years: We helped the company recruit a permanent head of engineering to carry the work forward. The original goal had been to find a new CTO. But a dedicated engineering leader turned out to be the right fit.

Outcomes

For The Client

The platform stabilized within months. The deeper transformation played out over two years. Here’s what changed:

• Full outages stopped. The system that used to crash entirely now ran reliably for the stakeholder’s operations across hundreds of properties.
• Financial audits back on schedule. Audits that had been dragging into September were completed by April. Penalties were largely avoided.
• From near-loss to growth. When we started, the company’s biggest client was threatening to leave. That would have meant losing roughly 80% of the business. Stabilizing the platform reversed that trajectory. Over the course of the engagement, the business grew roughly 40% in units managed.
• Permanent engineering leadership and a self-sufficient team. The company gained a dedicated head of engineering. Developers who once waited for instructions now owned technical decisions and produced code to a consistent standard.

What We Learned

Two years inside a rescue engagement taught us a few things we couldn’t have learned any other way.

• Adapt the playbook, but don’t water it down. We couldn’t copy-paste our exact process into an organization that had never had one. We adapted it to fit the culture, but we didn’t compromise on the fundamentals. Pushing through the friction was the right call.
• What’s obvious to you isn’t obvious to everyone. We walked in with assumptions about baseline engineering practices. The team had never been exposed to most of them. Treating that gap as a knowledge difference rather than a competence problem changed how we communicated and how fast the team moved.
• Fix the bleeding before you redesign the patient. The temptation in any rescue is to rebuild from the ground up. We stabilized the platform and overhauled processes in parallel, but both came before any attempt at deeper architectural changes.
• Earn trust through visibility, not promises. The client had just watched their CTO leave after months of failed negotiations. Consistent progress through working results built more confidence than any reassurance could.
• Start from a source of truth. Two years in, 70% of the codebase was still legacy. Instead of trying to fix everything at once, we cleaned one foundational area first and made it the reference point. We wrote automation tests against it and used it to validate business logic. That gave us two things. First, a concrete example of what good looked like. Second, a trusted base that made all future development faster. The full refactoring is happening now, in a new engagement built on that foundation.

Conclusion

A proptech company was about to lose its biggest client. The platform couldn’t deliver on the operations that mattered most. A referral brought them to Pragmatic Coders, and we spent two years rebuilding the engineering foundation from the inside.

The platform stabilized. The business grew. The team went from waiting for instructions to owning technical decisions with proper leadership in place. That’s what a successful rescue looks like.