Property developer·2019 to present

An end-to-end property sales and operations platform

A property developer ran sales across SAP, an outgrown CRM, and spreadsheets. One platform now carries it from lead to turnover.

Sector
Real Estate, PropTech
My role
Led discovery, architecture, full-stack delivery, deployment, and production support.
Stack
Laravel, Vue.js, Tailwind, MySQL, REST APIs, queued workers, AWS

In 2019, a property developer's residential sales operation ran across three systems that couldn't agree on a unit's availability or sales status. I led the platform build that joined the process from the first lead through property turnover.

Fragmented across three systems, and none of them agreed

Inventory and contracts lived in SAP. Leads sat in a CRM they'd outgrown. Everything the two didn't cover, which was most of the actual sales process, ran on spreadsheets.

The CRM was the sharper problem. It held leads and contact details, but it couldn't follow one from the campaign that produced it through qualification, into an opportunity against a specific unit, and on to a sale. A property developer's process is specific: how a hold becomes a reservation, what has to be signed before a booking counts, who approves what. None of that fit, so the real sale was tracked in a spreadsheet beside the CRM. Sellers worked both, and neither held the full record. Nobody could say what a campaign had actually returned.

There was nothing buyer-facing at all. A buyer's whole transaction ran through their assigned seller: whether the contract to sell was ready, which requirements were outstanding, whether a payment had posted, where the loan sat. Every answer meant messaging the seller and waiting. Sales managers and directors had the same problem in reverse, assembling their own pipeline by hand from whatever the sellers reported.

Manual re-entry was the visible cost, but conflicting data cost more. A seller couldn't tell a buyer whether a unit was still available, because it depended on which system they checked. Finance chased sales for contract details. Working out where a booking sat between reservation and turnover meant asking whoever happened to remember.

How I moved the workflow into data

I led discovery with my team and the client's stakeholders. The hard part was that their sales process was still being refined while we were building it. Stages moved, approvals changed, and new document requirements turned up mid-project. That ruled out hard-coding the workflow, because every operational change would become a rewrite.

So we worked the states out one stage at a time, writing down what had to be true before anything could move to the next. A lead can't become an opportunity until it's qualified and assigned to a seller. A hold expires if the reservation fee isn't paid inside the window, and the unit returns to available inventory on its own. A reservation can't become a booking until the contract to sell is signed and the buyer's requirements are complete. Turnover can't start until the loan account is set up and construction is complete. Each rule got its condition and its approver written down, instead of living in someone's head.

That became an explicit state model. Each lead and unit has a current state, and every surface reads from that shared record rather than keeping its own version. When the client later added a document to the booking requirements, it was a row, not a release.

We migrated the leads across and retired the CRM. SAP stayed as master data, and the platform reads from it and never posts back, because SAP holds the contracts and finance runs on them.

How the platform expanded beyond sales

We released the platform in stages. The first covered the part of the process spilling into spreadsheets every day: leads, opportunities and sales contracts. Workflows that were still changing internally were deliberately scheduled later. From there, we worked outward department by department: sales first, then billing and finance, followed by the teams handling loans and turnover.

Follow one sale through the platform. A campaign runs, and the leads that come in are tagged to it. A lead is qualified, assigned to a seller, and becomes an opportunity against a specific unit. The unit is held, becomes a reservation once the fee is paid, then a booking once the contract to sell is signed. From there it runs through billing and the loan application, then acceptance and turnover. That path is the workflow core, and the rest of the platform is a view onto it.

The buyer mobile app shows a buyer their own transaction: what stage they're at, what's outstanding, what's paid, where the loan sits. The seller portal is where an agent works leads and opportunities through to booking, and where their manager and director can see that pipeline without asking for it. The admin portal runs campaigns and inventory, the back office side of contracts, bookings, turnover and loan management, and reporting across all of it.

Becoming their operations platform wasn't the original brief. Sales kits, commissions and incentives, and announcements were each requested in later phases. The portals use the same underlying records, so a number in a director's report and a number on a buyer's phone comes from the same place.

What I still own

The engagement has run since 2019. As departments identify workflows that still sit outside the platform, we scope and bring them in without changing the core sales flow.

I continue to own the work from discovery on new workflows through to production support.

An end-to-end property sales and operations platform | Ryan Catapang