There's a post from an indie dev who built a small WoW reference site called Late Night Raid. The pitch is modest and honest: when he was looking up WoW Forever details himself, the facts were scattered. Launch dates, beta windows, price, level cap, new zones, dungeons, raids. All of it spread across many pages, so a returning player ends up clicking around just to assemble a picture that should fit on one screen. He built the site to cut that down, and then asked the room the question every maker eventually asks: do I add a database next, or class guides, or gear lookup, or a version timeline?
I want to reframe that question, because I think the fork he's standing at is a trap. Databases, timelines, class pages, gear tables, those are all presentations. They're views. If you pick one now, you're committing to a shape before you've locked down the thing that actually matters. The durable asset here isn't any page. It's the structured, hand-correctable record of facts underneath. Get that right and every one of those features becomes a rendering job. Get it wrong and you'll be re-typing patch notes into HTML for the rest of the project's life.
Why the pages are the disposable part
Game info ages in a specific way. A level cap is correct until an expansion ships, then it's wrong forever. A beta date is a rumor, then a confirmed date, then history. Prices shift by region and over time. The returning player doesn't care how pretty your dungeon page is; they care that the number on it is current and that they can trust it. That trust is a data problem, not a layout problem.
So the honest version of this site is: a clean set of rows that a human keeps correct, plus whatever pages you feel like generating on top. If you ever want to rebuild the front end, redesign it, or add that version timeline, you do it against the same rows. The pages come and go. The rows stay.
There's a wider signal across the indie work I keep seeing that backs this up. One dev rebuilt an RSS reader basically so he could change anything he wanted, because the value was in owning the thing, not in the framework. The lesson rhymes: own the layer that's expensive to recreate, stay loose about the layer that's cheap to regenerate. For a reference site, the expensive layer is the verified facts.
The build: normalizer, curated table, generated pages
Here's how I'd actually assemble it, and all three parts map cleanly onto what's available.
Start with intake. The facts arrive messy, pasted snippets from patch notes, forum threads, the kind of half-structured text where a date might be written five different ways and a zone name is buried in a sentence. You write a Python normalizer that reads those snippets and turns them into candidate rows: fact type, value, the version it applies to, a confidence flag, and the raw source text it came from. You don't need it to be clever. You need it to be consistent and to never silently drop something. Being able to run Python online means that normalizer lives next to the data instead of on your laptop, so re-running it on a new batch of notes is a two-minute job rather than a dig-out-the-script ritual.
The normalizer's output is deliberately not trusted. It proposes. A human disposes. That's the whole point of the architecture, because the forum reply on the original post already shows why: one commenter wants roadmap timing, mechanic changes, race and class skill updates, new zones, new exploration content. That's a lot of fields, and a lot of them are judgment calls a parser will get wrong. So the parser writes candidate rows and a person reviews them.
That review surface is a SQLite table. One row per fact, columns for the version, the category, the value, a status like draft or confirmed, and a last-checked date. Keeping it in SQLite rather than a pile of JSON or hardcoded HTML means you can sort, filter, and fix things in place. A SQLite editor is exactly the curation tool this project needs: when the next expansion bumps the level cap, you find the row, change the number, flip the status, done. No redeploy of content, no hunting through templates. The correction happens where the truth lives.
Then the pages. Every view the dev was debating becomes a query. The version timeline is just the fact table ordered by date and grouped by version. The dungeon list is a filter on category. A returning-player summary is a handful of the highest-confidence rows for the current version rendered on one screen, which is the original goal stated plainly. You generate static HTML from the table and put it behind web app hosting, so the public site is fast and the editing happens privately against the database. When you want a new view, you add a query and a template, not a new content pipeline.
What this changes in practice
The friction you avoid is the one that kills these sites. Without the data layer, every patch means editing prose in multiple pages, and inconsistencies creep in because the level cap on the summary page and the one on the class page drift apart. With a single curated table, there's one place a fact can be true, and every page reads from it. The returning player gets a consistent answer; you get a sane maintenance loop.
The trade-off is honest too. You're spending early effort on a normalizer and a schema instead of shipping another good-looking page, and that feels slower at first. It is slower at first. The payoff shows up on the third or fourth patch cycle, when updating is a few row edits instead of an afternoon. Whether that payoff materializes for any specific project is unverified, because it depends on how often the game actually changes and how disciplined the curation stays. I'm describing a structure, not promising a result.
A few boundaries worth stating plainly. This design assumes you're comfortable generating HTML pages and running Python for the normalization step; both fit the available capabilities. It does not assume any particular front-end framework or external cloud service, because mapping to those would be guessing. If you later want the normalizer to pull facts live from an upstream API, that would depend on whether such a model or endpoint is already available to call in-platform; it's not something I'd assume works until you've confirmed the specific source.
The reframe, said once more
The dev asked whether to add a database or a timeline. The better framing is that the database isn't a feature you add, it's the spine you build everything else on, and the timeline is one of its cheap outputs. Pages are how the information looks this month. The curated record is the thing you'd be heartbroken to lose. Build so that losing the pages costs you an afternoon and losing the data costs you the whole project, then protect the data accordingly.
For anyone sitting at the same fork, with a reference site in any niche, not just WoW, the pattern transfers directly. Normalize messy input into rows, let a human own the corrections, render whatever views you need on top. The site that lasts is the one where the facts outlive the layout.