Software gets built differently now
Why this matters
Section titled “Why this matters”Most stacks are assembled: a database here, a framework there, a UI kit from somewhere else, and glue code everywhere in between. Every seam is something a team — and now every AI assistant — has to learn, maintain, and keep in sync.
Cratis takes the opposite bet. One company designs the whole path — from the facts your system records, through the application that shapes them, to the screens people use and the tools that operate it — around one shared model and one set of conventions. We believe software built this way is better, more robust, faster to deliver, higher quality, and more cost-effective, because the seams you would normally hand-write and babysit simply are not there.
That same coherence is what makes the ecosystem AI-ready: conventions that are explicit and consistent are conventions an AI agent can follow. Cratis ships its conventions as AI skills, rules, and diagnostics, so assistants build with the grain of the platform instead of guessing at it.
One connected ecosystem — adopt it one piece at a time
Section titled “One connected ecosystem — adopt it one piece at a time”Designed together does not mean all-or-nothing. Each product stands on its own, and you choose what you need: run Chronicle alone as your event store, build with Arc without event sourcing at all, or take the whole stack and let value flow through the entire chain. Start with the piece that solves today’s problem — the rest are there when you want them, not before:
Built to deliver outcomes, not just features
Section titled “Built to deliver outcomes, not just features”Cratis is opinionated on purpose. The opinions are what carry the value:
- Built to keep history you can trust. Events are immutable facts, and read models derive from them — audit and replay are part of the design, not an afterthought.
- Built to remove glue. One C# model becomes typed frontend contracts; drift between backend and frontend becomes a build error instead of a production incident.
- Built to fit your infrastructure. A database-agnostic event store and multiple language clients mean the ecosystem adapts to you — not the other way around.
- Built to be adopted piecemeal. Every product is independently adoptable. Chronicle works without Arc, Arc works without event sourcing, Components is optional on top of Arc — you never buy the whole stack to get one piece, and nothing is wasted when you later add the next one.
- Built for people and AI together. Predictable, convention-driven codebases are easier for new developers to join and for AI agents to extend.
We believe this adds up to software that is more robust, faster to build, and more cost-effective to own. Why developers choose Cratis walks through the reasoning; The Cratis Stack shows the whole journey end to end.
Use one piece — or the whole thing
Section titled “Use one piece — or the whole thing”Modularity is a design commitment, not a marketing line. The products compose, but none of them holds the others hostage — each seam below is an intentional, supported adoption boundary:
-
Chronicle stands alone. Use it purely as an event store — from .NET, TypeScript, Kotlin/Java, or Elixir — with no Arc, no Components, and no other Cratis product involved.
-
Arc does not require event sourcing. Use application services, MongoDB, or Entity Framework Core for current-state behavior, and add Chronicle only where an event-sourced path fits.
-
Arc does not require Components. Generated TypeScript clients can be consumed directly or through Arc’s React packages.
-
Chronicle is not .NET-only. The client landing page maps each shipped client to its documentation and packages; the protocol details live in the Chronicle architecture pages.
-
Chronicle and its bundled local Workbench are available as MIT-licensed self-hosted software; authorized local use is separate from paid Cratis support, hosted coordination, or managed operational responsibility.
These boundaries do not establish compatibility with every package, provider, browser, runtime, topology, or product version. Check the documentation and package manifests for the combination you use.
Go deeper
Section titled “Go deeper”Technical depth lives in each product’s own documentation:
About this site
Section titled “About this site”Product repositories own their technical documentation, examples, packages, and released contracts. This site aggregates that material into one searchable set of tutorials, guides, explanations, and references.