About Cratis

Two people, and the software we'd want to inherit.

Cratis started from a straightforward frustration: the tools were good, but you spent your life keeping them in step with each other. Every layer knew a little and assumed the rest. The plan that was supposed to tie it together lived on a whiteboard, and stopped being true within a month.

So we built the thing where the pieces agree.

Who we are

The two of us.

Einar Ingebrigtsen

Co-founder and CTO

Created Cratis and wrote most of what it runs on.

Sindre Alstad Wilting

Co-founder and Chief Architect

Builds and maintains the platform alongside Einar.

The honest part

We're small. Here's what that actually means.

What you get

The person answering wrote the code

No triage tier, no account manager, no ticket escalated to someone reading the source for the first time. You get an answer from someone who already knows why it works that way.

What we do about the rest

Everything public, in writing

An open licence on the software you run, the source in public, a published roadmap, a security disclosure process, and a written continuity clause in every support plan. Not because we plan to disappear — because you shouldn't have to take our word for it.

What we won't do

Pretend to be bigger

You can count us, and you should be able to. We'd rather be a small company you can reach than a large one you can't.

The community

Open, and genuinely so.

The software your business would run on is open source and built in the open, where anyone can read the decisions being made about it. Cratis Studio, where your team designs together, is the product we charge for. We would rather draw that line plainly than blur it.

What we build towards

Values, and the ones that cost us something.

Every company lists values. These are the ones that actually change what we ship.

Empathy

Understanding who we are building for — a colleague, a customer, someone who inherits this in five years — is the whole job, not a step in it.

Simplicity

The internals can be complex. The surface you touch shouldn't be. Developer experience, front and center.

Readability

Code is read far more often than it's written. Naming is most of the work. We're not trying to save keystrokes.

Predictability

Surprises belong to birthdays, not in code. What we promise is what it does, consistently.

Testability

Specs are how a system explains itself to the next person. We favour BDD so the tests read like the behaviour.

Automation

If a computer can do it, make it do it. Repetition is where human error lives.

These come from the values we've published in the open since the beginning — the same ones that govern contributions.