Crew · Careers

What we commit to, towards our engineers.

A public commitment lasts longer than a promise made in an interview: this one is written, dated, and has not been withdrawn since.

5%

of the value of every new contract, paid to the engineering team

Base: the value of every new contract signed. Beneficiary: the engineering team. Announced publicly on 12 June 2024, applied since 1 July 2024.

In force since 1 July 2024

The commitment

Five percent, explained.

The question asked in June 2024 was this one: how do you reward the effort of an engineering team without stopping at a pat on the back and chocolate medals? The answer was a percentage, not a speech. For every new contract signed, five percent of its value goes to the engineering team. (1)

What it changes in practice: the value created at a client is not separated from the people who created it by a layer of subjective appreciation. There is no individual target to negotiate, no evaluation grid to contest, no argument about comparative merit. There is a signed contract, a base and a percentage. ▪

The original announcement, June 2024
The original announcement is one sentence: “for every new contract, 5% of its value will be awarded to the engineering team.” It was published on 12 June 2024 under the founder's name and ended with “valid until aborted” — a commitment that stands until it is publicly withdrawn.

The work

What you would actually work on.

Nothing in this stack is a declared skill: every name runs either at a client under contract or inside the product we build.

The stack we actually run

Talos LinuxKubernetesKubeVirtOpenTofuArgo CDRook-CephMinIOCloudNativePGPostgreSQLTrinoApache IcebergKafkaAirflowCiliumEnvoy GatewayKeycloakOpenBaocert-managerKServevLLMGrafanaOpenTelemetry

The stack layer by layer, on the crew page

Four environments, not one

What we run does not live only in a cloud. Three of the four environments we serve are under the client's control: their European cloud, their machine room, or a fully disconnected network. An engineer joining us has to know how to ship a signed artefact on physical media, not only push an image to a registry.

Systems that are not allowed to fail

Banking, public research, local government, industry. The constraints come with the territory: traceability, segmentation, security review, written release procedures. It is not the fastest ground to work on; it is the one where an architecture decision has to hold up two years later in front of someone who was not there.

We write what we run

Two Rust clients published, close to fifteen thousand lines: a gRPC client for Talos Linux, under mTLS and generated from the official protos, published on crates.io; and a Trino client we had to fork to add the spooling protocol. Going down to protocol level is part of the job, not a side project.

A product, not only engagements

We build Hyperfluid, an internal cloud of twenty services. Part of the engineering time goes to the product, part to client engagements, and the same person often does both within a quarter. What you write for a client sometimes ends up in the product — and the other way round.

The three domains, and what they cover

Data & Lakehouse
Data you can query, trace and move. TrinoApache IcebergMinIOCephAirflowKafkaPostgreSQL
Security & Governance
Architectures where a leak is not an option. KeycloakIstioCiliumcert-managerOWASPTalos
Artificial intelligence
Your models on your side, your data never leaves. vLLMTritonKServeKubeflowMCPpgvector

Hiring

How it goes, step by step.

Five steps, in this order. You talk to the founder, then to the team, about real code and decisions you have made.

  1. You write. An address, not a form. An email, what you have built, and a link to a public repository if you have one. Your message lands in an inbox read by an engineer, with no applicant tracking software in between.
  2. We reply. Every application gets an answer, including a no, and the answer says why. Timing — ⟨reply time⟩
  3. A first conversation, by video. With the founder. What you have built, what we invoice and to whom, and what the role actually demands — including how much time is spent on the client's site. Timing — ⟨duration⟩
  4. A technical conversation, with the team. About real code and architecture decisions you have made — why that one, what it cost, what you would do differently. No timed algorithm puzzle, no unpaid exercise that looks like deliverable work.
  5. A written offer. Salary, technical scope, on-site rhythm, and the mechanism described at the top of this page. What is not written in the offer does not exist.

On site and remote

Where the work happens.

The head office is in Montpellier. Part of the work happens at the client's site, on their tooling and in their offices: that is the company's main engagement model, and it requires a share of on-site presence.

The exact rhythm depends on the client. It appears in the written offer before you sign, with the location and the frequency, rather than being discovered on the first Monday. ▪

Applying

Who to write to, and with what.

Speculative applications are read by an engineer and get an answer. Write to the address below, subject “Application”, and say what you have built and what you want to build next. A public repository, a contribution or a piece of technical writing is worth more than a cover letter.

We do not list open positions: hiring follows signed contracts. An application arriving outside a live hiring round gets a clear answer rather than a file left open. ▪

contact@nudibranches.tech

See what we publish as open source Back