I’m Ludy, and I’m building chuppa.gg, an independent hub for game wikis, beginner guides, character and item references, builds, tier lists, and codes.

This is a content project, not a developer utility. But the engineering questions behind it are surprisingly interesting: how do you organize information that is interconnected, unevenly structured, and vulnerable to becoming outdated?

Start with relationships, not page templates

A character page, a build, and a tier list might all mention the same character. That does not make them interchangeable.

The reference describes the entity. The build recommends a configuration. The tier list compares options under some set of assumptions.

A useful conceptual model is:

Game -> Reference entries -> Beginner guides -> Builds -> Tier lists -> Codes Recommendation -> Referenced entities -> Supporting sources -> Applicable context

This is a design sketch, not a dump of the production schema. The important distinction is between describing something and recommending something.

The stack matters less than the publishing contract

I’m keeping this post stack-neutral rather than presenting an undocumented framework, database, or hosting setup as fact.

For this kind of site, the architectural contract is the interesting part: content storage feeds validation, validation feeds rendering, and rendering produces navigable pages with useful relationships.

Whether that pipeline uses files or a database, I would want checks for broken internal references, missing source URLs, duplicate identifiers, and content attached to the wrong game.

Those checks catch problems that a perfectly healthy build can otherwise publish.

Freshness is a modeling problem

A recently edited page is not necessarily a recently verified page.

That distinction becomes especially important for codes and balance-sensitive recommendations. A typo fix should not imply that someone retested a build.

My preferred design separates editorial changes from verification events and records what was actually checked. That is a direction for the content model, not a promise of automated verification.

What I want feedback on

I’m interested in how other developers handle source relationships and update context in content-heavy applications.

Would you model a build as structured data with prose attached, or as prose with references embedded? How would you expose uncertainty without covering every page in warnings?

Take a look at chuppa.gg and tell me which relationships you would make more explicit.