Tenhaw delivers through a pool of senior associates rather than a salaried bench, and the route in is narrow: associates are people the founder has already delivered alongside, selected because he has seen their work. That is the quality mechanism: everyone who joins an engagement has already worked with us. If we have not worked together, the useful thing is a piece of work in common, not an application. What follows is the whole mechanism: how someone reaches the pool, the screening every associate completes before touching a client estate, what an engagement looks like from your side of it, what we select for, and the three things this arrangement does not give you.
Tenhaw is James Rooney plus a pool of associates: senior AI builders he has worked with directly and would put in front of a client without hesitation. Each is someone whose work he has seen at first hand, selected for one thing above all, which is that they ship. Every associate on your engagement is screened to BS7858 standard before they touch your estate, and contracted to written confidentiality and data-handling obligations. Every person on your engagement is senior, with no pyramid of juniors behind them.
Every associate is someone we have delivered alongside, hands on, on real work rather than on an interview. We are not going out to market to find your team after a statement of work is signed.
The pool is weighted towards builders who get things into production, not towards people who present well. The two-week proof of concept on our live insurance engagement is the standard of pace we hire against.
BS7858-standard screening covering identity, right to work, employment history and criminal record checks, completed before any client access, with written confidentiality and data-handling terms agreed before it.
Associates are engaged for your work rather than carried between engagements, so there is no utilisation gap priced into your rate. That is a large part of why the rate card is what it is.
He leads every audit personally and provides oversight on everything else, including programme management. He is accountable for the outcome and he is the escalation route, not a partner who appears at the kickoff and the closedown.
In the order it happens.
If we have not worked together, an application is a weaker signal than a piece of work in common.
Six things, and only one of them is a technology.
The same terms the client is shown, in the same words.
BS7858-standard screening before any client access, written confidentiality, and the client's data-handling requirements. Confidentiality survives the end of the engagement indefinitely, and on our current insurance engagement it means the client is not named anywhere, including here.
Access is requested against the principle of least privilege and time-boxed, with a documented offboarding step on exit rather than an email afterwards. Our default on a proof of concept is to work locally against mocked services, or in a dedicated environment on synthetic data.
Where a client has an approved enterprise tenancy we work inside it rather than bringing our own. Tenhaw does not resell or mark up models, platforms or licences, so nothing you specify becomes revenue for us and there is no reason to design anything larger than the job needs.
James provides partner oversight on every engagement and leads the audits personally. He is accountable for the outcome and he is the escalation route. If an engagement is going wrong, the conversation is with him and it happens early.
The screening, access and contractual position are published in full on our security and assurance page, including the assurance we hold today and what is still in progress. The delivery method is published on The Tenhaw Way, and the engineering handbook behind it is open on GitHub.
Three things the arrangement does not give you.
Not a covering letter. A system you built, who used it, and what you would do differently. If we have delivered together, say so first and skip the rest. We read everything and reply to less than we would like.
General enquiries, including anything commercial, go to hello@tenhaw.com.
The 30-minute discovery call is the same one every other page offers. We will cover where your organisation sits on the agentic curve and which rung to start on, and you will leave with a rough scope whether you engage us or not.
most start with a fixed-price AI Readiness Audit · £44,000 · 4 weeks · working prototypes
In practice, by having delivered alongside James Rooney already, or by being referred by somebody who has. Tenhaw does not go to market for people after a client signs a Statement of Work, because that is the practice that makes a small supplier risky, and it is why everyone on an engagement is someone we have already worked with. If we have not worked together, an application is a weaker signal than a piece of work in common, so make the work the introduction. There is no application form, no take-home exercise and no panel. If you want to start the conversation anyway, email us and expect it to be longer and more sceptical than it would be for someone we have delivered with.
BS7858-standard screening covering identity, right to work, employment history and criminal record checks, completed before any client access, with the same standard applied to associates and employees alike. It is evidenced during the client's supplier onboarding. Alongside it, associates are contracted to the same confidentiality, data-handling and no-sub-contracting obligations as an employee, confidentiality survives the end of the engagement indefinitely, and access to a client estate is granted against the principle of least privilege and time-boxed, with a documented offboarding step on exit.
Small, senior and visible. Delivery teams are two or three senior people, and that is the whole team. The cadence is monthly value delivered, committed to and reported against, and a month that delivers no measurable value is reported as a failed month rather than explained away. The build method is AI-engineering-first, which means requirements become structured markdown, a model interrogates the whole corpus for gaps and contradictions before any code is written, and the build runs against the full requirement set with a security review roughly every fifth prompt, pair-programmed with the client's own engineers throughout. Partner oversight is on every engagement and the escalation route is a person.
Associates are engaged for specific client work rather than employed, and there is no bench. The trade runs in both directions, since a client is not paying for utilisation between engagements and we cannot promise an associate a pipeline. Joining the pool is not an offer and does not come with a start date. If you need continuity of income, this is the wrong arrangement.
Six things, and only one of them is a technology. That you ship, with something a person can look at and a story about what broke. That you can build with AI as the primary tool, not as autocomplete, because our published method treats the requirements as the source code and the model as the compiler. That you will pair with the client's engineers, since a proof of concept nobody internal can reproduce is a demonstration rather than a capability. That you will recommend against a release when it is not ready, which we have done at least once on every engagement we have run. That you find the constraints of a regulated estate interesting. And that you will tell a client exactly where the evidence stands. Today that is working proofs of concept built in regulated estates, with productionisation in progress.
No, and we tell clients the same thing. No names, no published CVs and no headcount for the pool. The model supplies senior people for each engagement rather than a salaried bench, so no utilisation gap is priced into the rate, and our comparison pages say when a larger firm is the better buy.
Everything Tenhaw has delivered runs on Microsoft Azure, including Azure OpenAI, with delivery through GitHub, and the build method itself is Git, markdown and a model at maximum reasoning rather than a framework. Beyond that, the useful skills are the ones that transfer across clouds: retrieval and permission-aware knowledge access, tool calling and integration, evaluation harnesses and ground-truth sets, and the identity and access design that decides whether any of it clears a security review. The site lists the platforms we have a view on and no delivery behind, which includes Amazon Bedrock, Amazon SageMaker, Google Vertex AI, Kubernetes, Terraform and Apache Airflow, so an associate who has delivered on one of those brings something the firm does not have.
Pairing, on effectively all of it. The entire two-week proof of concept on the live engagement in the London specialty insurance market was built alongside one of the client's own engineers, because pair-programming with the receiving organisation is the deliverable on a Tenhaw engagement rather than a nice-to-have. Recruiting and upskilling the client's permanent team is a stated deliverable rather than a side effect. The reasoning is plain. A proof of concept nobody internal can reproduce is a demonstration rather than a capability, so skill transfer is measured like any other outcome. An associate who prefers to build alone and hand over at the end is good at something Tenhaw does not sell.
No. Most of Tenhaw's work sits in financial services, where a second-line risk function is a co-author and the evidence an engagement produces matters as much as the system, but nobody is expected to arrive as a compliance specialist. What is expected is that you find the constraints of a regulated estate interesting rather than irritating, because they shape the work rather than sitting alongside it. The current flagship engagement is a proof of concept built inside a live London specialty insurance estate, now in its productionisation phase, so an agentic build here means working exactly where regulated delivery and agentic engineering meet.
A great deal, and it is not optional. Delivery teams are two or three senior people, so nobody sits between you and the client while you pair with their engineers through the build, and the monthly value commitment is reported to them rather than smoothed over, because a month that delivers no measurable value is reported as a failed month. Two things are asked of you in those conversations. Say exactly where the evidence stands, since inflating a proof of concept costs Tenhaw the only asset it has. And say when a release is not ready, which we have done at least once on every engagement. Partner oversight sits behind you, and James is the escalation route.
A system you built, who used it, and what you would do differently, sent to james.rooney@tenhaw.com. If we have delivered together, say that in the first line and skip the rest. The conversation that follows turns on the same material: what you shipped, who it was for, what broke when real people used it, and what you recommended against. A covering letter tells us how you write about work rather than what the work was, which is why we ask for the thing itself. We read everything and reply to less than we would like, so lead with the work rather than the framing.
As long as the client's engagement runs, and that is deliberately finite. Engagements are retainer-shaped and monthly rather than milestone-shaped, the exit date is agreed with the client at kickoff, and the contract carries thirty days' notice either side, so nothing is open-ended by design. Built to leave is the operating principle rather than decoration, and it shows in the terms. The client owns all code, documentation and work product from day one, and upskilling their permanent team is part of what is being delivered, so a well-run engagement ends when it said it would. As a marker of pace, month three of the live London specialty insurance engagement is the productionisation phase.
Yes, and it is a stated deliverable rather than a favour at the end. Recruiting and upskilling the client's permanent team sits alongside the system itself, so it runs from pairing on the build through to helping shape and fill the roles that will own the work afterwards. On the live insurance engagement the client's engineer finished the two-week build saying they were 70% confident they could run the process without us. Skill transfer is measured rather than assumed, and a number like that is treated as an outcome rather than a nice remark. If working yourself out of a seat sounds wrong, this model will grate.
Often not, and never before screening completes. The default on a proof of concept is to work locally against mocked services, or in a dedicated environment on synthetic data, because most of what a build needs to prove can be proven without production records. Where real access is genuinely required it is requested against the principle of least privilege, time-boxed to the engagement, and closed through a documented offboarding step on exit rather than an email afterwards. Your screening is evidenced during the client's supplier onboarding, so the access conversation happens with their security people. Confidentiality does not expire either, which is why the client on the current London specialty insurance engagement is not named anywhere, including on this page.
You say so, out loud and to the client. Recommending against a release has happened at least once on every engagement Tenhaw has run, usually where a launch date was being defended rather than a readiness assessment being made, so it is a normal event here rather than an act of nerve. Part of what a client is buying is somebody able to say it, which is easier for an outside team than for their own people and still not easy. You are not doing it alone, because James provides partner oversight on every engagement, is accountable for the outcome and is the escalation route, and that conversation happens early rather than at a closedown.
No. Tenhaw does not resell or mark up models, platforms or licences, so nothing you specify becomes revenue for us and there is no reason to design anything larger than the job needs. Where a client has an approved enterprise tenancy we work inside it rather than bringing our own stack, and the default toolchain is Claude Code with OpenAI models and Gemini, best tool for the case, running inside the client's infrastructure. In practice that means your architecture arguments are about the work rather than about a partner agreement, which is not true everywhere.
There is no standing list of vacancies. When a specific skill is genuinely being sought it appears in its own section on this page and comes down once it is filled, so what is here is current rather than a careers list nobody maintains. If that section is not showing today, nothing specific is being advertised. That is less limiting than it sounds, because seats open when client work does rather than on a hiring calendar, and they are filled from people James has already delivered alongside. So the useful move is to be known before the work exists, which is a conversation rather than an application.
All of it, and we would rather you did. The method is published in full on The Tenhaw Way, including the parts that go wrong, and the engineering handbook behind it is open on GitHub at github.com/Tenhaw/engineering-handbook. Every requirement becomes structured markdown, a model maps and interrogates the whole corpus for gaps and contradictions before any code exists, and only then does the build run against the full requirement set at maximum reasoning, with a security review roughly every fifth prompt. Read it and decide whether that is how you want to work. Most people who would dislike it find that out there, which saves us both an afternoon.