# How we engineer

> The four commitments that decide what Tignex builds, what it refuses to build, and what it writes down in public.

- Updated: 2026-09-12
- Source: https://tignex.com/engineering/
- Language: en-US
- Author: Muhammet Şafak

---

Tignex is not tied to a single product, language or technology. What holds it
together is a short list of commitments — the ones below — that every project
under the organization is expected to keep, whether it is a CLI tool, a
specification or a piece of server infrastructure.

## Control stays with you

Every project is open source, and open in the way that matters: you can read it,
fork it, and run it on your own machines. Nothing we publish is a client for a
service we operate, because that is the shortest path to a dependency you cannot
remove.

- Self-hosting is the first-class path, not a paid tier.
- Data stays in systems you already control.
- Leaving is a supported operation — export before lock-in.

```bash
git clone https://github.com/CommitBrief/commitbrief
cd commitbrief
go test ./...
```

## Interoperable by design

We prefer open formats and documented protocols to convenient private ones, even
when the private one would ship sooner. A format only one implementation
understands is a promise that expires the day that implementation does.

> If another team cannot write a second implementation from the specification
> alone, the specification is not finished.

This is also why projects here keep their own names and homes. A standard that
can only be adopted by adopting our whole catalogue is not a standard — it is a
brand with extra steps.

## Production-oriented

The target is software that survives contact with systems that are already
running: real data, real load, real migrations, and an operator who was not in
the room when it was designed. Features that only hold together in a demo do not
ship.

:::note{title="In practice"}
An upgrade path before a feature, a way to observe it before a way to configure
it, and defaults that are safe for someone who never reads the manual.
:::

## Transparent by default

Decisions, trade-offs and limits are written down where they can be argued with —
in the repository, in the specification, and in the [engineering
notes](/notes/). That includes the unflattering parts: what a project does
badly, what it has not solved yet, and what we decided not to do.

## What this rules out

Taken seriously, these commitments remove options. No telemetry that we would not
want pointed at us. No `open-core` feature walls in the middle of a protocol. No
release that depends on infrastructure only we can run. The list is short on
purpose: it has to be possible to hold every project to it.