Articles
Policy · Standards · May 2026 · 8 min read

A craftsperson’s code.

The principles every Relay engineer signs before they ever take a press. Written down so a customer can hold us to them.

Every Relay engineer signs this before they ever take a press. We publish it for two reasons. The first is so a customer can hold us to it. The second is so an engineer thinking about joining knows what kind of work, and what kind of restraint, the work involves.

It is short by design. It is also literal. Each line is a thing we have, at some point, watched go wrong, and decided to write down so it goes wrong less often.

One. The customer’s name is on it

Code that ships from a press goes out under the customer’s name. Not ours. We do not embed credit lines, beacons, comments with our URL, or anything else that would let a future reader trace the diff back to Relay. The customer is the author. We helped.

Two. We do not write what we do not understand

If a press requires a system or a domain we do not know, an unfamiliar database, a regulated workflow, a language we’ve only seen in a tutorial, we say so, immediately, and we hand the press to someone on the bench who does. We do not learn on a customer’s clock unless the customer has explicitly bought learning time. The bench is wide enough that this almost never costs the customer a press.

Three. We never silently rewrite

If we change something the customer wrote, the customer sees the change before the change ships. Not after. We use diffs. We narrate the diff. The customer says yes or no. The number of times an engineer has shipped “a small fix” that turned out to be a quiet rewrite is large. We refuse the pattern.

Four. We tell the customer when to stop

The hardest line for an engineer to say is do not ship this; rewrite it. We say it. The point of a press is not to keep the build moving. The point of a press is to put a person who has shipped this kind of system before in front of the decision the AI cannot make on its own. Sometimes that decision is no.

Five. We hand off, and we say so

If we cannot finish a press inside the time it should take, we hand it to another engineer, and we tell the customer we are doing it, and the new engineer reads what came before. Continuity is not the absence of handoff. It is the cleanness of the handoff. The customer should never be the person carrying context across a swap.

Six. We do not optimize the press into nothing

The temptation is real. A press that resolves in nine minutes instead of fourteen looks like a win on the dashboard. It is not, if the resolution is “ship it” on a build that should not have shipped. We measure the press by what holds, not by what closed.

Seven. We protect the customer’s data

We touch a customer’s code, environment, and sometimes their users’ data. We treat all of it the way we would want a stranger to treat ours. Nothing leaves the session that the customer did not see leave. No paste into ChatGPT, no screenshot to a friend, no “quick check” with a tool that retains. The session is the perimeter.

Eight. We are kind

Most presses are someone admitting they are stuck. Some are someone admitting they are scared. None of them are an opportunity to demonstrate seniority at the customer’s expense. We answer the question that was asked. We answer the question behind the question when it’s clearly there. We don’t make the customer feel small for not knowing.

Eight lines. The next year will probably teach us a ninth, and a tenth. When it does we will write them down here, with a date next to them.

Relay Standards. Last revised May 2026.

AI changed who can build.
Relay changes the way they ship.

  1. 01In seconds.A real engineer joins your build.
  2. 02To launch.Same engineer takes you through.
  3. 03And beyond.Same engineer keeps it running.
Talk to sales