Build Log
One Dataset, Many Explanations
The most expensive content bug is a page that confidently disagrees with its own tool. The v3 architecture reduced that risk by giving facts one source of truth.
Data first, prose around it
Public-holiday dates live in versioned JSON for 2026 and 2027. The calculator reads those records at runtime. A Python generator reads the same records to build state pages and holiday guides. Dates are not copied into each article by hand, so one verified update can propagate across the site.
This split keeps hard facts and editorial explanation distinct. A writer can explain why an Easter bridge is efficient without retyping Good Friday or Easter Monday. The generator owns the date; the article owns the interpretation and caveats.
A content ecosystem without content drift
The first generated ecosystem included a national guide, eight jurisdiction pages, six holiday guides, and editorial standards. Each page added structured data, breadcrumbs, internal links, and a route back to a prefilled calculator. The tool stayed the product while the surrounding pages made its method and coverage legible.
Shareable URLs encode state, days, strategy, and school-holiday preference. The canonical remains the clean homepage because a user-configured plan is a state of the application, not a separate editorial page.
What became standard
Data-driven sites generate repeated hard facts from the verified dataset and reserve hand-written prose for context. Generators live outside the deployment tree, and quality scans compare the rendered routes with their source data.
Follow the same records through a state page, a holiday guide, and the calculator.