From a character idea
to a compiled mod.

01 / The problem

Make a technical workflow accessible.

A character mod involves much more than writing a description. Cards need effects, triggers, assets, and code that fits the game's APIs. A creator also needs a build environment and a way to package the result.

I built Slay around an editable project model. Creators work with game concepts in the browser; the application handles the translation into source and a downloadable artifact. My work spans the editor, code generation, compilation service, cloud features, and maintenance.

02 / Architecture

A structured project connects the editor to the compiler.

The Next.js and TypeScript application provides the authoring interface. A code-generation layer translates the project into C# source and supporting assets. A separate .NET build service compiles the generated sources and returns the packaged output.

Cloud saves and version history add persistence around that workflow. They let the project remain editable and recoverable after the first build, rather than treating generation as a one-time export.

03 / Earlier AI work

Generation in stages, with checks between them.

Current status: AI generation and credit purchases are unavailable. The editor and compiler are the live product. This section describes the earlier implementation.

The earlier Claude-based pipeline split character generation into mechanics, foundation, expansion, and finalization passes. Mechanics were established before card generation so later passes could reference the same custom concepts.

• Structured output. Tool-use responses and Zod schemas checked generated data before it entered the project.
• Model selection by task. Mechanics and bulk card generation used different models, with estimated token cost logged per pass.
• Progress and failure handling. The application streamed progress and included credit-refund handling for failed generation.

That work sits alongside a conventional editing and compilation workflow. A model response is an input to the system; it still needs validation, a successful build, and evaluation in the game.

04 / Reliability

A successful response is only the first check.

The repository includes regression tests around generated code, request validation, and build policy. The compile policy restricts input paths and file types, uses service-owned build configuration, and filters the compiler environment. Its production invocation is configured for isolated Linux namespaces and resource limits.

Those are concrete controls, not a claim that a public compiler is risk-free. Build success also does not establish that a mod loads or behaves correctly on every game version.

1. Valid projectDoes the data satisfy the editor's expected structure?
2. Successful compilationDoes the generated source build against the supported references?
3. Game compatibilityDoes the artifact load and behave correctly on the target game branch?
4. Useful resultCan the creator make something they actually want to play?

The public compile count measures activity at the build step. It does not answer the other three questions.

05 / Product decisions

Keep the creative loop free. Charge for convenience.

Building and compiling characters remain free. The paid Pro plan adds cloud capacity, version history, priority compilation, and other convenience features. Slay has paying users; revenue and subscriber totals are not published here.

The product's public costs page exposes configured infrastructure costs alongside usage. That makes the ongoing storage and compilation work visible, while keeping financial estimates separate from measured activity.

06 / Evidence & limits

What the numbers mean.

The figures above are a saved 30-day snapshot observed on September 5, 2026. They are not a live dashboard.

6,759 successful compile events

The sum of client-recorded successful-compile events in the reporting window. Repeat builds are included. This is not a count of unique mods or independently verified game sessions.

2,278 distinct browser IDs

Distinct anonymous browser identifiers across recorded events in that window. One person can use multiple browsers, and identifiers can change. This is not a verified user or customer count.

Paying users

The product has paid subscribers. No subscriber count, revenue, retention rate, or profitability claim is implied by the usage figures.

The public product and its usage page are available to inspect. The implementation descriptions here summarize the project source; they are not an independent security audit or a published benchmark.