Property Management Platform

Sanitised and conceptual. This describes the shape of the problem and the engineering approach in generalised terms. It is not a representation of any employer’s proprietary architecture, source code, data or internal metrics.

Context#

A property management platform is deceptively broad. It holds listings and media, tenancy and occupancy state, operational workflows, and the people using all of that from a phone while standing in a building. Since June 2024 I have been the lead software and DevOps engineer on the Deityvillas (GHECS) platform.

This is the role where the previous decade's threads converge: architecture, mobile delivery, applied machine learning, and infrastructure. One scope, with one person accountable for the join between them.

The engineering problem#

Platforms of this kind accumulate. Listings logic reaches into tenancy logic, tenancy reaches into operations, and within a year every change is a whole-system change, every deploy is a whole-system deploy, and the cost of being wrong rises until the team stops moving.

The work was to establish boundaries, in-house backend microservices with their own responsibilities, and, just as importantly, to build the delivery machinery that makes independent services something other than a diagram. Services you cannot deploy separately are a monolith with extra network calls.

What I owned#

• Architected and implemented scalable in-house backend microservices in PHP, establishing the service boundaries for the platform.
• Built the companion mobile application in React Native, shipped to both iOS and Android from a shared codebase.
• Implemented a machine learning model to predict user engagement on the platform's web application, and optimised model inference using TensorFlow Serving, treating the model as a production dependency with its own latency and availability profile, not as an offline artefact.
• Set up the infrastructure pipelines: CI/CD, Dockerisation and AWS S3 storage, for repeatable deployment and system reliability.

Conceptual architecture#

Property management platform, conceptual service layout

1. Clients

   • Web applicationBrowser
   • Mobile applicationReact Native · iOS + Android
   HTTPS / JSON

2. Edge

   • API surfaceRouting · Auth · Rate limiting
   Internal calls

3. Services

   • ListingsPHP
   • Tenancy & operationsPHP
   • Engagement inferenceTensorFlow Serving
   Reads / writes

4. State

   • Relational storeTransactional data
   • CacheHot reads
   • Object storageAWS S3 · media

Delivery pipeline#

Delivery pipeline, conceptual stages

1. 01CommitVersion control
2. 02Build & testAutomated checks
3. 03Container imageDocker
4. 04DeployPer-service release
5. 05VerifyHealth & rollback path

Engineering considerations#

Boundaries should follow the business, not the org chart. The useful split in a property platform is by what changes together, listings and media move at a different rhythm from tenancy state, which moves differently again from operational workflow. Splitting along those seams keeps the blast radius of a change proportional to the change.

Media is the heaviest thing the system moves. Property software is photographs. Putting object storage on the diagram as its own dependency rather than an implementation detail of one service is a decision, not a drawing convention, it is what keeps large uploads and image delivery from becoming a property of the application servers.

An ML model in production is an availability problem first. The interesting part of serving an engagement model is not the model. It is that inference now sits in a user-facing path: it needs its own scaling behaviour, its own timeout, and a defined answer to "what does the page do when the model is slow?" TensorFlow Serving exists precisely so that inference can be operated as a service rather than embedded in application code.

Mobile is a release-cadence problem. Web deploys when you say so; mobile deploys when a review queue says so. Shipping React Native to two stores means designing backend changes to be tolerant of clients that are several versions behind, the API contract has to age gracefully.