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.
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.
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.
We can teach a framework, a model API, a deployment target. These are the ones that have to arrive with you.
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.
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.
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.
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.
No portal, no application form, no seventeen-field profile builder. One email address, read by someone who can actually make a decision.
admin@xelement.ioNot looking for a job but want to work together? Book a call instead