NDTZ
NDTZ runs a Discord community from two directions at once: slash commands inside the server, and a browser panel for the people who administer it. Both talk to the same configuration, and the panel is built so a server owner never has to read documentation to change something.
Two interfaces, one configuration
The bot process and its control panel are the same Node process. Express listens on a loopback port, nginx terminates TLS in front of it, and the panel is served as static HTML, CSS and vanilla JavaScript with no build step at all. That decision keeps the deploy story to one command and means the panel cannot drift out of sync with the bot it configures.
Authentication is Discord OAuth2 with the identify and guilds scopes. A visitor only ever sees the servers they can genuinely administer, because the panel checks Manage Server against Discord rather than keeping its own idea of who is allowed to do what.
Two panel generations, live simultaneously
A single environment variable selects which frontend Express serves: the current design, or the original one kept as a rollback. Both speak to the same API. The newer panel patches one configuration module at a time; the older one posts the whole configuration object, and that older route is still supported rather than deleted.
Switching between them is a one-line change and a process restart — no migration, no data change. Keeping the rollback path working costs a little duplication and buys the ability to undo a design decision on a live system in seconds.
Aggregate-only public data
The panel exposes one unauthenticated endpoint. It returns the bot name, an invite URL, and three counts. It deliberately returns nothing per-guild and nothing per-user, and that constraint is written down in the specification rather than left to whoever edits the route next.
This site consumes that endpoint over HTTPS for its live status strip. It has no database credentials and no access to the bot process — the coupling is one public URL, so nothing this portfolio does can affect a running community.
Rendered level cards
Member level cards are composed server-side as images with a native canvas binding, including animated output. Members edit their own card through a signed link rather than an account, which avoids building a second identity system for a feature that only needs to prove one thing: that this request came from this member.
Where it stands
The structural decisions have not needed revisiting. Keeping the panel and the bot in one process, serving the frontend without a build step, and restricting the public endpoint to aggregate counts were all settled early and none of them have had to be undone since.
What remains is additive: more modules, more of the panel moved to the newer design, and more of the community-facing features that the configuration system already anticipates. The work ahead is features, not repairs.