A private operations platform for a game studio whose work otherwise lives across repositories, documents, conversations and spreadsheets.
View the case study · Doomed Interactive · Discuss the work
DOS — the Doomed Operation System — was created for Doomed Interactive to give a small game studio one operational view across project state, design context, team coordination, communication and studio spend.
It is intentionally an internal product rather than an open platform. The value is not another place to duplicate work; it is a readable view over the work and evidence already produced by the studio's repositories and operating processes.
This public repository contains only a source-free case study. Runtime addresses, user identities, credentials, database definitions, security implementation and deployment configuration are excluded.
A studio's operational state is fragmented by default. Development activity belongs with the project, design evolves in its own documents, decisions happen in conversation and business costs live somewhere else again. That makes it difficult to answer simple questions without reconstructing the situation by hand.
DOS brings those signals into one focused control surface, designed for a known team and a real working cadence.
- Project workspaces with task state, backlog, design context, results and activity.
- A journal-derived board that reflects work recorded alongside the projects.
- Team channels, direct communication, presence and voice collaboration.
- Studio-level responsibilities, tasks, subscriptions and expenses.
- Operational evidence that makes delivery state easier to inspect.
The central product idea is simple: the dashboard is a read model, not a second authority. Project operations are recorded as an append-only history, then replayed into the board a person sees. Re-reading the same operation converges on the same result, which keeps the control surface aligned with the work instead of allowing it to drift into a competing task store.
The diagram above is a presentation-level system view. It communicates the product boundary without publishing endpoints, resource identifiers or an operational runbook.
DOS presents delivery as a sequence of recorded evidence rather than a status label with no history behind it. The release name and checksum shown in this illustration are fictional presentation data, not production identifiers.
DOS uses a TypeScript and React interface deployed on Cloudflare's edge platform, with managed storage and realtime primitives selected for a compact private team. Exact module boundaries, authentication flows, schemas, integrations and deployment details remain private.
DOS was built by NYOWORKS for Doomed Interactive. This case study describes NYOWORKS's product, interface and engineering contribution; it does not claim ownership of Doomed Interactive's name, identity or wider catalogue.
The live operations panel is private and no credentials are published. A guided product or architecture walkthrough can be arranged for a serious commercial or hiring conversation under appropriate confidentiality.
See NOTICE.md for usage, attribution and rights information.