Work with us
The way software gets built is changing. Assistants now write, refactor, and review a growing share of the code, and teams ship faster than their architecture was designed to absorb. What survives that pressure is an explicit model: facts the system actually recorded, intent the code states out loud, and conventions a new developer and an AI agent can both follow without guessing.
That is what Cratis is built for, and it is what we help teams build.
We maintain Chronicle, Arc, Components, and the rest of the stack. If you are evaluating event sourcing, adopting Cratis, or trying to get an existing system into a shape you can move quickly in, you can work with us directly.
If you need help
Section titled “If you need help”You do not need a finished design or an approved budget to start a conversation. These are the moments teams usually reach out:
- You are evaluating event sourcing and want an honest answer about whether it fits your system — including the cases where it does not.
- You are adopting Cratis and want the first slices modeled right, because the early ones set the pattern everything after them copies.
- Your model has drifted — projections that no longer answer the questions the business asks, or events that record mechanics instead of facts.
- You want a codebase agents are productive in, with conventions and analyzers that keep generated code on the rails instead of quietly off them.
- You need a second opinion before you commit to consistency boundaries, tenancy, storage, or a migration path.
- Your team knows the framework but not the modeling. The syntax is learnable in a week. The modeling is the part worth teaching.
What we can help with
Section titled “What we can help with”| Need | What it looks like | What you end up with |
|---|---|---|
| Event modeling | A working session over your domain — commands, events, read models, and boundaries on a shared canvas | An event model your team agrees on, and the slices to build first |
| Cratis adoption | Slice selection, product choice, and a path from the system you run today | A sequenced adoption plan with the first slice specified |
| Architecture review | A read of your model, consistency boundaries, tenancy, storage, and failure modes | A written review with the risks ranked and the fixes named |
| Implementation help | Pairing, pull-request guidance, or focused development on a bounded slice | Working slices in your codebase, built the way the stack intends |
| AI-ready foundations | Conventions, analyzers, and .ai guidance set up so assistants build to your standards | A repository where developers and agents follow the same rails |
| Teaching event sourcing | Domain events, consistency, projections, replay, versioning, and the operational trade-offs | A team that can model without us in the room |
| Teaching the stack | Chronicle, Arc, Components, and the CLI, taught through the full-stack loop | A team productive in the stack without shadowing someone |
| Production readiness | A review of TLS, storage, secrets, deployment, observability, replay, and backup plans | A checked list of what must be true before you go live |
Building for the AI age
Section titled “Building for the AI age”There is a reason we lead with the model rather than the tooling. An assistant is only as good as the structure it works inside: give it a vague codebase and it produces vague code, faster. Give it recorded facts, typed contracts that span the stack, and conventions a compiler or analyzer can check, and its output starts landing inside the lines.
Cratis ships that structure. Generated proxies break the build when a contract drifts, analyzers catch the shapes that are wrong before review does, and the .ai rules and skills are written to be read by assistants directly. A large part of any engagement is putting those rails in place, so that moving faster does not quietly cost you the model.
For what this looks like in the products themselves, see AI-native development, the editor and assistant plugins, and code analysis.
How we work
Section titled “How we work”- Start with a conversation. Describe the context and what you need. We will tell you whether we are the right fit, and say so plainly when we are not.
- Scoped and time-boxed. A workshop, a review, or a bounded piece of development with an agreed outcome — not an open-ended retainer.
- Private when it needs to be. Your domain, your code, and your roadmap stay yours.
- Open when it does not. If the answer would help everyone, it belongs in the documentation or in Discord, and that is where we would rather put it.
What to include when you contact us
Section titled “What to include when you contact us”Enough context for us to tell you honestly whether we can help:
- What you are building or evaluating.
- Which Cratis products you use, or expect to use.
- Whether this is greenfield, brownfield, or a system already in production.
- The kind of help you want: modeling, review, development, training, or troubleshooting.
- The rough timeframe, and whether the work has to be private.
When we are not the right fit
Section titled “When we are not the right fit”Being direct about the limits saves everyone a meeting:
- The question can be answered in public. Community and help is free, open, and usually faster.
- You found a vulnerability. Use Security for responsible disclosure instead.
- You want a general .NET or React consultancy. We work on the model, the stack, and the architecture around them.
Contact us
Section titled “Contact us”Email oss@cratis.io with a subject that starts with Working with Cratis, and include the context above. We will come back to you on whether we can help, what shape the work would take, and when we could start.
If you are still deciding where to begin, Adopting Cratis lays out the paths from an existing system, and Learning paths routes you through the documentation by role.