Careers

No listings.
A standing invitation.

We don't post roles we haven't committed to filling. But we read every serious introduction that arrives, and we've made room for good people who wrote to us before a role existed.

Small team.
Unreasonable standards.

Most AI work in this industry stops at the demo. Ours starts there. The interesting part of the job — the part that takes real engineering — is everything after the prototype impresses the room: the evals, the guardrails, the integration with a system written before you were born, the monitoring, and the person who owns it on the Tuesday after launch.

That shapes how we work day to day. You own things end to end — you won't be handed a ticket carved out of someone else's design. You'll sit with the client, understand why the workflow is broken, argue for the simplest thing that fixes it, and then be the one who ships it and watches it run.

We are deliberately small, which cuts both ways. There is no layer of management between you and the decision, and no process to hide behind either. If you need a large organisation to provide structure, you will find this uncomfortable. If you've been waiting for permission to just fix the thing properly, you'll like it here.

We publish our thinking in the open — fifty pieces, none of them gated — and we open-source work where a client agrees. Everything in Labs is live and breakable by anyone who visits. That's a standard to work to, not a marketing exercise: it means what we build has to survive strangers poking at it.

The last thing, and the one most people notice first: we tell clients when AI isn't the answer. You will be backed for saying so, even when the honest version bills less. Nobody here is asked to defend a recommendation they don't believe.

Four things we can't
teach you.

We can teach a framework, a model API, a deployment target. These are the ones that have to arrive with you.

01

You've shipped something that outlived the demo

Not a hackathon project or a notebook — a system that ran unattended, broke in an interesting way, and that you then had to fix while people depended on it. That experience is the whole job.

02

You're suspicious of your own output

You reach for an eval before you reach for a bigger model. You assume the confident answer is wrong until something verifies it. You'd rather ship a refusal than a plausible fabrication.

03

You can say "this doesn't need AI"

Out loud, to a client, when it's the truth and the alternative bills more. Judgment about what not to build is rarer and more valuable than knowing how to build it.

04

You write like a person

Docs, runbooks, commit messages, and the email explaining why the plan changed. We hand over everything we make, so writing clearly isn't a soft skill here — it's part of the deliverable.

The honest caveat:we're a small firm, not a scale-up with a hiring plan. There may be no role open when you write, and we'd rather say that than run a pipeline of interviews leading nowhere. What we will do is read what you send, reply like a human, and remember you when something opens.

Send it to a person.

No portal, no application form, no seventeen-field profile builder. One email address, read by someone who can actually make a decision.

admin@xelement.io
  • Your CV or a link to your work — GitHub, writing, a thing you shipped. Whatever represents you best.
  • A few lines on something you built that reached real users, and what broke about it.
  • Optional and genuinely welcome: tell us something on this site you'd have built differently.
  • Please skip the cover letter written by a language model. We do this for a living — we can tell, and it tells us nothing.

Not looking for a job but want to work together? Book a call instead