I rebuilt a property portal with AI agents. Writing it was the easy part

Most of what gets written about AI for property portals is a list of features: recommendations, a chatbot on the listing page, automated valuations. Or it’s a prediction that ChatGPT is about to eat the portals. OnlineMarketplaces, pulling together company disclosures in September, counted 43 live AI initiatives at Rightmove alone, and found LLMs were still under one percent of direct traffic for most portal operators. Both of those are worth knowing. Neither tells you what happens when somebody actually builds a portal with AI agents, and that’s the part I can talk about, because I did it this year.

Why I built one

In January and February I was between contracts, and LinkedIn was full of “I built Slack in a single day” posts. That’s not true. But there was a real shift in what the agents could do in January, and it made me ask a better question: if I’m an expert and I know everything about the subject, how much of a boost do they actually give me?

I started at realestate.com.au in 2010 and I’ve done pretty much everything in real estate platforms since, so property was the obvious pick. A portal is also properly end to end: agent tools, listings, agency management. The bulk of it was built in about six weeks, and it’s now around half a million lines of code, with agents merging their own work to production since January. I used all of my engineering rigour on it, so it’s tested and built to scale, but at the same time I was driving it to deliver more than would have been possible before.

Speed-running ten years of REA

I didn’t start with the architecture it has now. Originally the agent portal and the admin portal sat on the same backend database as everything else. Then the listing ingestion started hitting that database so aggressively that it crashed the site. I split it and put a queue in between, and now the agent and admin side owns the database and the public site and search sit behind the queue as a facade. That’s exactly the solution a whole bunch of companies came to. I’d basically speed-run ten years of REA development.

That kept happening. I’d hit a problem and go, oh, that’s why they did that. Yeah OK, I’ll do that. And that’s the bit the “Slack in a day” posts leave out. The agents write code fast, but they write it fast in whatever direction you point them, and knowing the direction is the domain knowledge. It’s possible, but I have super deep knowledge of these platforms, and you need that depth across all of it, not just the parts you’re comfortable with.

The REA product that took two years

One of the first things I worked on at REA was the studio product, codenamed Huxley. It’s basically an agent website builder. The first version took about six, maybe eight months, with a team of eight developers, mind you, and then we spent most of another year modifying and improving it. The agents churned through an equivalent in a few days, plus about a week of messing around with it afterwards.

The speed on its own isn’t the interesting part. REA also re-architected the internals of that kind of system at one point, and it took 12 months. Historically you couldn’t A/B test architectures. You committed, and then you spent a year changing it if you got it wrong. Now you can build both and compare them. Rewriting a small piece in a different language is a day or two, not a quarter, so long as the codebase is well factored and modular and not spaghetti. You’re not locked into decisions the way we were.

Keeping it cheap to run

A lot of the work after the first build went into making it cheap to run. I went back to SvelteKit because it’s much lighter weight. It runs on a fraction of the memory Next.js does, which drastically reduces the cost and makes it faster. Then I moved towards statically rendering pretty much everything into S3 buckets as it comes off the queue. Everything that isn’t a search page or the map page is static, so it can’t put extra load on the database or the infrastructure, and for the vast majority of pages you’re paying only for bandwidth.

It’s also built so I can roll it out in a new country in less than a week, and it’s fully multilingual. The legislation differences between countries are real and they’re a consideration. The platform isn’t what slows you down.

What’s still hard: listings and visits

That’s the thing, though. Every two or three years in Australia some agent group got together and wrote a portal. Being able to write a portal is nothing new. Then they discovered that not having visits was the biggest problem. It’s a distribution problem, and it’s always been a distribution problem. You can build a Slack clone in no time flat, but open source alternatives to Slack have existed for a very, very long time.

The other half is listings. The big problem with entering any market is getting the listings. Even if an agency buys in and says yes, you can have my listings, they often don’t control them as much as all that. The listings sit in some CRM system you have to integrate with, and often the CRM is owned by the major portal and won’t add you. Even if you make it a paid service, being able to get those listings regardless is a real strength for whoever already has them.

I was evaluating this as a threat as well. If anyone can come along and build platforms, then life gets more difficult for REA Group and the other big portals, whoever, with all these pop-ups. It’s still just not that easy. And that’s before you even get to distribution, getting people to actually use it.

What I’d tell a portal CTO

I keep telling CIOs and CTOs they need to be aware that they’re losing a moat. Before, you had some protection from the little upstart because a lot of effort had gone into building the platform. You already had the customers, and anybody coming after you had to put significant effort into building it. That second part is mostly gone. The code is now the cheap bit.

What’s left is listings access, the relationship with agents, and traffic, right? If I were running a portal I’d be looking hard at who controls the flow of listings into my site, and at how much agents depend on me for things other than leads, because that’s exactly where a new entrant will go. My own plan for a new market is tools agents get value from straight away without needing traffic, then their listings, then content for search, and only once there’s traffic, leads. That’s the theory, and it’s untested for the most part. The code is actually solid, it just isn’t proven, and solid code isn’t the same as a proven business.

The effort it took you to build your platform isn’t protecting you the way it used to, so I’d spend the time on the agents and the listings.

I’ve written up how the agents actually work on the portal, and the guardrails that let them merge to production, in How I let coding agents merge to production.