An Australian online property-sales platform where agents, vendors and qualified buyers collaborate through live auctions, private treaty offers, documents and communication.
Visit the product websiteMoving a property sale online means translating more than the auction-room countdown. Buyer qualification, state-specific registration, property documents, role-based visibility, offers and counteroffers, payments, notifications and the closing state all need to stay coherent for agents, vendors and buyers.
As part of the Corporate Interactive delivery team, I worked across the React front end and established Java/Spring platform. My contribution covered the live auction experience and websocket lifecycle as well as the less visible operational workflows—property setup, team administration, permissions, offers, notifications, payments and AWS delivery—that make the public transaction possible.
SoldOnline brings the property auction room and private-treaty process into one online platform. Agents can prepare and manage a property sale, vendors can follow its progress, and qualified buyers can register, review the available information and participate from wherever they are. The product supports live auctions as well as private and timed-private-treaty offers, with property documents, communication, offers and counteroffers collected around the same transaction.
That public experience sits on top of a wider operational system. A property has agencies and team members, contacts and vendors, registration requirements, visibility rules, sale settings, notifications, payment decisions and administrative support. Live bidding is the most visible moment, but its integrity depends on all of those states being correct before the auction starts.
I developed SoldOnline within the Corporate Interactive team alongside other engineers working in the same established platform. The repository shows a collaborative delivery model with feature branches, pull requests and frequent integration across the React application, Java services and AWS deployment work. We had to evolve existing workflows without treating the older server or the operational knowledge embedded in it as disposable.
As Principal Engineer, I worked between product behaviour and implementation detail. That meant helping the team turn real-estate rules into explicit interface states, tracing bugs across front end and server behaviour, reviewing changes, and making sure improvements to the bidder experience did not leave agents or support staff without the controls they needed.
My contribution included the auction-room interface, alerts and bidder history; shared websocket connections and dispatch behaviour; buyer registration and terms; offer and auto-bid presentation; vendor and agent visibility; mobile adjustments; property upload and configuration; team-member and administration tools; billing and payment flows; and AWS release integration. Much of that work was about making roles and transitions visible—who can see a contact, whether an auction is pending, suspended or complete, and which action is valid next.
I also spent time on the small operational details that determine whether a platform is usable in practice: clearer support paths, resilient property imagery, useful alerts, correct time handling and responsive controls during a live event.
SoldOnline taught me that “real time” is primarily a correctness problem. Websockets can deliver an update quickly, but the product still needs ordering, reconnection behaviour, permission checks and unambiguous state transitions. It also reinforced the importance of building the operational side with the same care as the headline experience. An elegant auction screen is not enough if an agent cannot configure the sale, a buyer cannot complete registration or support cannot understand what happened. Mature delivery means designing that whole chain with the team, not optimising the most visible screen in isolation.