---
title: Work with us
description: Work directly with the people who build Cratis — event modeling, adoption, architecture review, implementation help, AI-ready foundations, and training.
---

import { CardGrid, LinkCard, Aside } from '@astrojs/starlight/components';

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.

<CardGrid>
  <LinkCard title="Contact us" description="Email the Cratis maintainers with your context, the kind of help you need, and the timeframe." href="mailto:oss@cratis.io?subject=Working%20with%20Cratis" />
  <LinkCard title="Ask in the community first" description="Discord is open, free, and often faster when the question can be discussed publicly." href="/community/" />
  <LinkCard title="How dedicated help works" description="What separates a private engagement from community support, and how to prepare an inquiry." href="/professional-help/" />
</CardGrid>

## 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

| 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

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](/ai/), the [editor and assistant plugins](/plugins/), and [code analysis](/code-analysis/).

## 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

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

Being direct about the limits saves everyone a meeting:

- **The question can be answered in public.** [Community and help](/community/) is free, open, and usually faster.
- **You found a vulnerability.** Use [Security](/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.

<Aside type="note" title="Availability is finite">
We build and maintain Cratis, so engagements depend on availability, fit, and the relevant consultancy, employer, and conflict-of-interest arrangements. Community support on Discord stays open and best-effort regardless.
</Aside>

## Contact us

Email [oss@cratis.io](mailto:oss@cratis.io?subject=Working%20with%20Cratis) 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](/adopting-cratis/) lays out the paths from an existing system, and [Learning paths](/learning-paths/) routes you through the documentation by role.