Case study / 01

Calamity

The full toolkit for running a live online game — analytics, campaigns, content, the launcher and player tools — built as one system instead of a dozen subscriptions.

LauncherArmoryWikiLive ops

RoleArchitecture, backend, frontend, desktop, data and operations — solo

TimeframeLive product · continuously operated

FastAPI
React
DuckDB
Parquet
Celery
Tauri 2
Redis
WebSockets

The problem

Live games usually rent an entire software department.

Analytics, email, push, content management, patch delivery and community tools usually arrive as separate subscriptions. Each adds a login, a bill and one more place where the game’s data lives.

Calamity needed one platform its team could understand and run end to end, without handing live-ops data and product decisions to a dozen vendors.

The system

One login across product, operations and data.

Four admin panels share a FastAPI foundation, while the public armory, wiki, player app and desktop launcher each show their audience only what they need.

Product & community

Public wiki with a bespoke CMS, full-text search, secret previews and Markdown export.
Armory and build planner over 403 items, 89 skills and 111 recipes extracted from Unity.
Tauri desktop launcher with signed updates, repair, branches, playtime and friend chat.

Live operations

News workflow with HTML-safe AI translation into 14 languages across five selectable models.
FCM push and SMTP email campaign suites with presets, scheduling, test sends and per-recipient logs.
Signed build release lifecycle and manifests consumed directly by the launcher updater.

Data

Parquet staging, ten-minute compaction and 16 atomic rollup tables behind a nine-tab dashboard.
Eight nightly player segments plus deterministic daily and weekly anomaly reports.
Custom MCP server with eight guarded analytics tools and a PII deny-list.

Production workflows

The handoffs the software removes.

Open a flow to see how separate tools behave as one system — from an internal signal to the thing a player receives.

01Signal → campaignData, message and delivery stay in one place.

Filter economy, retention or player-segment data in the analytics admin.
Save the audience and compose push or email from a reusable campaign preset.
Translate, test, schedule and inspect recipient-level delivery logs.

02Signed build → playerRelease operations and the desktop updater share one source of truth.

Prepare a release and signed manifest in the launcher admin.
Publish the selected branch while the lifecycle records build state and history.
The Tauri launcher verifies, patches or repairs the install before enabling Play.

03Unity data → public knowledgeGame data is extracted once and reused across player tools.

Extract items, skills and recipes from the Unity project into validated data.
Use that data in the Armory planner while editors build guides in the Wiki CMS.
Review through a secret preview, then publish searchable content and Markdown export.

Interactive previews

Pick a tool and walk through the real workflow.

One compact product tour covers the admin stack and the player-facing tools. Switch scenarios instead of scrolling screenshots; every private value stays explicitly illustrative.

Analytics workbench

Switch between overview, segments and money mechanics; change the range and inspect hand-rolled SVG charts.

Illustrative dataset · real panel structureRe-created from the real nine-tab panel. The production dashboard reads a DuckDB/Parquet pipeline and uses hand-rolled SVG charts too.

Public engineering numbers

A live-ops stack with its complexity made explicit.

These are engineering scope, not audience reach — what one person had to design, ship and keep running in production.

lines of first-party source: ~107.6k; Across 329 files
HTTP API endpoints: 141; Documented public count
backend tests: 528; Across 43 files
rollups / tabs / MCP tools: 16 / 9 / 8; Analytics scope
languages / AI models: 14 / 5; Validated translation workflow

What this proves