I built a property tool that shows what suburbs cost to LIVE in, not buy. The cheapest to run turned out to be the most expensive to buy.

A few months ago I was looking at Brisbane suburbs and realised something. Every property site shows you what a house costs to buy. Almost none show what the suburb costs to run once you live there. Council rates, water, the commute, insurance. The stuff that quietly drains a few hundred dollars a month and that nobody puts in one place before you sign.

So I built SuburbCost. It pulls together council rate schedules, water utility charges, ATO driving rates and insurance estimates for 1,615 Queensland suburbs, and shows the true annual running cost for any two suburbs side by side.

I want to share the build, the data findings, and the part I'm genuinely stuck on, because the stuck part is where I'd value other people's experience.

THE STACK, AND WHY IT'S BORING ON PURPOSE

Vanilla HTML, CSS and JavaScript. No React, no Next.js, no framework at all. The entire site runs off a single JSON file holding the suburb data. Static files on Vercel's free tier, GitHub for version control.

I used Claude Code as my main dev environment to write the comparison logic, generate the suburb pages, and build the scripts that turn the JSON into static HTML. When you have 1,615 pages to generate from structured data, a generator script plus static output beats a database and a server for a project at this stage. No backend to maintain, no database to secure, near-zero hosting cost, and every page is fast because it's just a file.

I'm not saying this is the right call for every project. But for a content site that's mostly read-heavy and SEO-driven, the simplest possible stack removed a huge amount of work I would otherwise have spent on infrastructure instead of data and content. The data is the product here, not the tech.

THE FIRST FINDING THAT SURPRISED ME

Once the data was in, I ranked all 514 Greater Brisbane suburbs by annual running cost. The cheapest suburb to run a house in is Brisbane City at about $5,151 a year. The most expensive is a rural suburb past Ipswich at over $22,000 a year, almost entirely because of how far residents drive.

Here's the part I didn't expect. The cheapest suburbs to run are also the most expensive to buy. Brisbane City, Spring Hill, Kelvin Grove. They're cheap to run because the people living there barely touch a car, so the commute cost is near zero. But the purchase price is the opposite story entirely.

Then it got more interesting. Some inner suburbs that should be cheap to run, because the commute is short, get knocked off the cheap list by flood insurance. New Farm and Teneriffe sit right on the river. Short commute, but insurance estimates two to three times higher than a low-risk suburb the same distance out.

So the pattern is: closer to the city drops your commute cost, closer to the river raises your insurance. Two suburbs the exact same distance from the CBD can land on opposite ends of the cost ranking depending on which of those wins. That's the kind of thing you only see when you put all the costs in one place, which was the whole reason to build the thing.

DISTRIBUTION, WHICH IS WORKING BETTER THAN I EXPECTED

I've put almost no effort into traditional marketing. The audience is people actively researching a suburb, and they're already gathered in specific places, so I went to those places.

I posted the running cost data to r/AusPropertyChat and r/brisbane. Not a link drop. Just the data as a post, with no link in the body, and let people ask for the source in the comments. One post hit a few thousand views with real engagement, people checking their own suburb against the numbers and arguing about the flood figures, which kept the thread alive for days.

The lesson there, which I suspect applies broadly: lead with the thing people actually want, the data, and let the link be something they pull out of you rather than something you push. A Reddit post that gets removed for being promotional is worth nothing. One that survives and accumulates comments ranks in Google for months.

THE PART I'M STUCK ON

Indexing. The site has 1,615 suburb pages, comparison pages for the most-searched pairs, and a growing set of data articles. Google Search Console shows about 91 pages indexed so far, with over 1,600 sitting in "Discovered, currently not indexed." I know this is normal for a new domain with no authority, Google is crawling slowly because it has no reason to prioritise me yet. The backlinks from Reddit have helped, the indexed count is creeping up.

But I'd genuinely value hearing from anyone who's grown a large page-count site from zero. Specifically: what actually moved the needle on getting Google to crawl through the long tail faster? Was it backlinks, internal linking structure, content velocity, something else? I've done the obvious things, sitemap submitted, internal links between suburb and comparison pages, schema markup. The bottleneck now seems to be pure crawl budget on a young domain, and I'm curious what others did to break through it.

WHAT I GOT WRONG

I tried setting up monetisation infrastructure too early. Applied to an affiliate network for the insurance comparison piece and got rejected for insufficient traffic. Useful, if blunt, feedback. It told me clearly that distribution has to come before monetisation, not alongside it. So right now there's no revenue. The plan is a mortgage broker referral fee, a small insurance affiliate once I qualify, and a cheap paid report. But all of that waits until there's enough traffic and trust to justify it.

WHERE IT'S AT

Live, indexing slowly, getting its first real traffic from Reddit, pre-revenue. The data seems to genuinely land with people once they see it, which is the signal I care about most at this stage. Everything else is a distribution and patience problem.

Happy to answer anything about the static-site approach, the data sourcing, or the Reddit distribution. The tool is here if you want to see it: www.suburbcost.com.au