readme
Togichu's website is a custom Kirby CMS build — the official web presence for Togichu, a VTuber and Twitch Partner. The goal was a branded, fast, mobile-friendly hub where fans can find her models, the artists behind every design, subathon history, commands, and every place to find her — outside the platforms she lives on.
Beyond a static portfolio, the site pulls live data: a Twitch live/offline pill in the nav, an auto-updating follower count, and a rolling 30-day "hours streamed" figure tracked from her past broadcasts. A Panel-toggled debut mode can replace the whole site with a single countdown teaser that flips back to the full site automatically at launch. Code ships to the live server on every push, while her Panel content edits are preserved and backed up automatically.
stack
- PHP
- v8.2+
- Server-side templating + Kirby core
- Kirby CMS
- v5.4
- Flat-file CMS
- Vanilla JS
- —
- No framework — DOM, events, lightweight scripts
- Modern CSS
- —
- Per-page stylesheets, custom-property design tokens
- Twitch API + DecAPI
- Helix
- Live status, follower count, hours-streamed tracking
- Github Actions
- —
- Push-to-deploy over FTPS + scheduled content backup
decisions
Brand-first, not template-first. I leaned into Togichu's character palette and visual identity from the very start — magenta/peach on deep charcoal, custom display type, animated glow and ring motifs — rather than building something neutral and skinning it later. The site had to read as her, not a portfolio template with a logo dropped in.
Flat-file over a database. I chose Kirby's file-based CMS instead of a database backend for portability and near-zero operational overhead — a solo creator's site shouldn't need a MySQL server to update a social link. Blueprint-driven editing lets her manage models, credits, and stats herself without touching code, and keeps every migration as simple as moving files.
Live data instead of hardcoded numbers. Stats that go stale the moment you type them — follower count, hours streamed — are pulled live. Followers come from the open DecAPI; the 30-day "hours streamed" figure is self-tracked from her Twitch VODs by a daily cron that recomputes a rolling window (so a missed run self-heals). A live/offline pill reads Twitch directly. No user OAuth and no secrets ever sit on the page.
Push-to-live, without ever clobbering her edits. Every commit ships to the cPanel host over FTPS via GitHub Actions, but the deploy deliberately excludes content — so code updates can never overwrite her Panel edits or uploads. A scheduled job mirrors the live content back into git as a backup, giving a conflict-free two-way sync between code (mine) and content (hers).
Launch as a toggle. A single Panel switch turns the whole site into a debut teaser with a live countdown and a one-tap calendar reminder, then auto-reverts to the full site at the debut date/time — no redeploy and no manual flip on launch day.
Performance on heavy character art. VTuber art is large by nature, so I used Kirby's thumb API aggressively — viewport-sized, lazy-loaded images with priority hints on the hero — so the site stays fast even though it's image-dense.
retro
What worked. Committing to the brand identity early paid off — it feels custom, not generic. The flat-file model made the editor genuinely usable for a non-technical owner and kept everything portable. Pulling in live Twitch data made the site feel alive rather than a static brochure, and the push-to-deploy + auto-backup pipeline made it effectively maintenance-free for her day-to-day.
What didn't. Early on I left too many options open in the blueprints, trying to be maximally flexible. It created decision fatigue during content editing — fewer, more opinionated fields would have been the better call. I also lost time to a Kirby gotcha: it reserves the /api/ path for its own API, which silently 404'd my custom live-data routes.
What I'd do differently. Stand up a proper staging environment from day one instead of validating against the live server — I got away with it, but it was reckless. I'd also lock the content model down sooner and design the live-data endpoints behind a clean internal route from the outset, rather than discovering the routing constraint mid-build.