Why Cratis
The honest version.
You're comparing options, so we'll say our conviction out loud: we believe keeping the full history of what happened — event sourcing — is worth it in almost all cases. Nearly every business runs on information, information flows and business processes, and that's exactly what it serves. Here's where we're genuinely different, where we're not, and when you should pick something else.
What changes day to day
Instead of… you work with…
| Instead of | You work with |
|---|---|
| Duplicating request and response shapes in C# and TypeScript | One C# command or query model, generated into typed frontend proxies |
| Spreading one feature across controllers, handlers, clients and UI folders | A vertical slice organized by behavior |
| Rebuilding screens by hand after a write | Observable queries and components that follow the read model |
| Rebuilding authentication, tenancy and identity plumbing per service | AuthProxy at the edge, Arc identity and tenancy inside, Chronicle namespaces underneath |
| Teaching every developer and assistant a project-specific architecture |
Strong conventions, analyzers and .ai guidance
that make each feature look like the rest
|
| Locking event history to one language or database engine | An open, documented boundary, with language and database coverage stated by product and version |
| Debugging from logs alone | Events, observers, and read models visible in current tools; replay is a deliberate operational action in supported CLI and Workbench versions |
The four things we'd defend
What we actually claim.
One model, end to end
The point isn't that Cratis has many packages. It's that the packages agree about how an application is shaped. A command, an event, a read model, a tenant, an identity, a React form and an operating tool are parts of one model — not islands with separate conventions. That agreement is what takes the friction and repetitive work out of the day-to-day: one set of conventions to learn, and every feature shaped like the last one.
A history you can question
Event sourcing optimizes for understanding change, not storing the latest value. Events are facts: immutable, past-tense, single-purpose. Read models are disposable, because the events are the state. And with Cratis it stays familiar to the people building it — even if they have never worked this way before.
Rails an agent can follow
Analyzers that fail the build on convention drift, skills that teach assistants the conventions, and an MCP server that makes the running store legible. A convention you can break silently isn't a convention — it's a suggestion.
Public Build source and documented boundaries
Cratis Build is developed in public under the license stated by each repository. Chronicle has an open, documented boundary, while client and storage coverage varies by product and version. Chronicle can be used without Arc, and Arc can be used without event sourcing.
When assembling parts
Choose the smallest boundary that solves the real problem.
A focused library can be the better answer. Cratis earns its keep when the expensive gaps are between design, backend, frontend, history and operations.
When the boundary is genuinely narrow
A backend-only service, one database, no shared design problem and no cross-language contract drift may not need the wider stack. Fewer moving pieces are a benefit when they solve the whole job.
When coherence is the requirement
Cratis Build joins Chronicle's event lifecycle with Arc's typed C# → TypeScript → React continuity. Workbench, CLI, and Chronicle MCP then expose documented operating workflows whose coverage varies by tool and version.
The commercial boundary
Three offers, with the line drawn plainly.
Public runtime source and operating tools
Chronicle, Arc, Components, Workbench, CLI, and Chronicle MCP are developed in public under the license stated by each repository. Their documented Build capabilities do not require a Studio seat or production feature key.
Paid collaborative design
A hosted Preview for modeling together, exploring supported behavior, and improving runtime understanding. Studio provides export for supported model content; available formats, retention, and later access follow the hosted product and applicable terms.
Paid expertise and responsibility
Support, architecture review, model sprints, first slices, production readiness and founder-led workshops, subject to the signed agreement for the engagement.
The part most sites leave out
When Cratis is the wrong choice.
Because the products are separable, "is Cratis a good fit?" is really several questions.
You're not on .NET
Chronicle has a documented, open boundary with clients for TypeScript, Kotlin, and Elixir. Coverage varies by client and version; .NET remains the primary experience.
Your slice is genuinely current-state-only
Reference data, settings, a small admin surface. Keeping full history is pure cost there. Arc over a traditional database is the simpler boundary, and it's a first-class path.
It's a prototype you'll throw away
Use it anyway. The conventions and scaffolding make even a prototype fast to stand up, so there's no reason not to. And if it lives on, you're already on a foundation built for the long run.
You want the largest possible community
Ours is smaller than the biggest alternatives — we're young in the public eye. It's also growing, helpful, kind, and inclusive: we answer questions and join topics quickly, and issues raised on Discord have often been resolved within hours. You'll find us at conferences and in the wider community too.
When none of it fits — a couple of static pages or a non-.NET backend — Cratis is more than you need, and that's fine.