School Scout: Australian School Search & Comparison

Choosing a school should not require seventeen browser tabs, three spreadsheets, and the investigative instincts of a mildly stressed detective.

Yet that is roughly where many parents end up. The useful information exists, but it is scattered across government datasets, school websites, ranking tables, PDFs, and pages that were not designed to be compared side by side.

I built School Scout to make that research easier. It brings Australian school data into one place so parents can search by area, compare schools, understand the main metrics, and keep a practical shortlist for the calls, emails, and school tours that come next.

It does not choose a school for you. It helps you get from “Where do I even start?” to a manageable set of schools worth investigating properly.

The product idea

School research usually mixes two different jobs:

1. Discovery: Which schools are nearby or relevant?
2. Decision-making: Which of those schools deserve a closer look?

Most school websites are built to present one school. Government datasets are built to publish data. Ranking sites are built to rank. None of those jobs is quite the same as helping a parent compare several real options.

School Scout is built around that missing workflow:

• search by suburb, postcode, school type, sector, and other filters
• explore public academic, enrolment, staffing, and community-context data
• compare up to five schools side by side
• save a separate shortlist with websites, phone numbers, email addresses, and locations
• leave the screen and continue the decision in the real world

That last step matters. A table can tell you about enrolment numbers. It cannot tell you how a school feels at 8:45 on a Tuesday morning.

Compare lists are not shortlists

One surprisingly important product decision was keeping the compare list and shortlist separate.

A compare list is temporary. You might add five schools because you want to inspect their numbers together. Some will be removed after thirty seconds.

A shortlist means something stronger: these are the schools you may contact, visit, or discuss with your family. That is why shortlisted schools show practical contact details rather than acting like a second copy of the comparison table.

It sounds like a tiny naming distinction. It is actually the difference between browsing and acting.

Tech stack talk

The stack is deliberately small: Go, templ, Datastar, and SQLite.

Go, templ, and Datastar

The frontend is mostly HTML rendered by Go. templ provides typed components, while Datastar handles the interactive parts such as changing filters, updating result tables, managing comparison state, and patching the relevant HTML back into the page.

That last part is what I like most. Datastar lets the frontend feel immediate without moving the application into the browser. Change a filter and Go queries SQLite, renders the new result, and sends back the exact fragment that changed. The frontend is a projection of server-side state, expressed as HTML rather than a second data model made of JSON and crossed fingers.

You could call this CQRS-flavoured, with a fairly large asterisk. Requests express intent, queries read the authoritative state, and the server returns a purpose-built view. But School Scout does not maintain separate command and read models, so calling it full CQRS would oversell it. It is closer to server-driven UI with clear query and view boundaries.

Embedding SQLite with the app

SQLite is an embedded database in the literal sense. It runs inside the application process, with no database server sitting across the network. The read-only school database also ships with the application, so the code, schema, and data snapshot move together.

That is wonderfully boring infrastructure. A release cannot pair new query code with an old schema by accident, and a rollback restores the matching code and data together. Go opens a local file and gets on with the job.

SQLite is also far more capable than its "little local database" reputation suggests. In one internal benchmark on a tiny cloud machine, it handled about 400 reads per second and 300 writes per second. The test used a read-your-writes loop on a 50 KB JSON blob, which is a stranger and probably harsher workload than the ordinary School Scout request. It is not a production traffic claim, but it is a useful reminder that small software can do serious work.

For a search-and-comparison product, this is a good fit. The browser gets the responsiveness people expect, but the architecture still behaves like a normal website. Links are links. Forms are forms. Pages have real URLs. Revolutionary stuff, apparently.

Making public data understandable

Publishing a metric is not the same as explaining it.

School data comes with acronyms, percentiles, rankings, ratios, and enough caveats to construct a small legal shelter. A parent should not need to learn the data model before using the product.

School Scout tries to keep the original data useful while adding plain-language labels, help text, consistent comparisons, and enough context to stop one number becoming the entire story.

That is especially important for rankings and community measures. They can be useful signals, but they are not universal scores of school quality. The interface treats them as evidence to inspect, not a podium on which every school must stand.

Creating infographics reliably with LLMs

School Scout also pushed me to find a repeatable way to create infographics with LLMs. Asking an image model to invent the information hierarchy, place every label, preserve the facts, and make the result attractive in one prompt is asking for trouble. The picture may look polished while a heading wanders off or a number quietly mutates.

The reliable workflow is to separate structure from style. I use a canvas tool so the LLM can map the layout and content first, then I make small edits while everything is still easy to move and text is editable. Once the structure is correct, I can pass that composition through an image generation model for a final stylistic pass if the graphic needs it. I have a detailed blog post coming on the full process, including where the handoffs tend to go wrong. With LLMs the last 10% of a job is the whole job now.

Trust is part of the interface

Sponsored school placements are clearly labelled and do not change rankings, metrics, comparison results, or explorer order. The current process is reviewed manually before anything is published.

That boundary is not decorative copy near the footer. If parents cannot tell where the data ends and promotion begins, the product has already lost the useful bit.

Key takeaways

Technical:

• Server-rendered HTML and selective SSE updates are enough for a genuinely interactive data app
• Datastar can turn server-side database queries into a responsive interface without duplicating application state in the browser
• SQLite can handle much more than its modest reputation suggests, even on small hardware
• Shipping code and data together makes schema compatibility and rollback much easier to reason about

Product:

• Search, compare, and shortlist are different stages and should feel different
• Contact details are more useful at the end of the journey than another decorative score
• Public data needs explanation, not just presentation
• Trust decisions belong in the product architecture, not only in a privacy-policy paragraph

School Scout began as a better table for Australian school data. It has grown into something more useful: a path from a very large pile of information to a small set of real conversations.

That is the goal. Less homework about schools, more time actually getting to know them.