PitTechs / For Agencies and Consultants

The AI engineer behind your client work, not in front of it.

Your client asked for something AI-shaped and you do not want to hire for it, refuse it, or hand it to a stranger. Send us the scope. You get numbered deliverables at a fixed price in writing, each with a written acceptance criterion, delivered under your name to a client who never has to know we exist.

Send us a client scope

Fixed price agreed before any work starts. You keep the client and the relationship. We stay invisible unless you want otherwise. One build at a time, because this is not a volume bench.

$ scope your client's brief, repo, prototype
$ quote numbered deliverables, fixed price, acceptance criteria
$ build retrieval, evals, traces, guardrails, plumbing
$ handover their repo, their infrastructure, your name on it
What we take

Three things worth subcontracting, and all three are the half that is scarce

Prompting is not the scarce part. Plenty of people write a good prompt. What decides whether your client's AI feature survives contact with their users is the engineering around it.

1. Your client's AI feature, hardened.

It demos well and it will not hold. We add retrieval that cites real sources so answers can be checked, evals so you can tell when quality drops instead of hearing it from a complaint, traces so a bad answer can be explained afterwards, and guardrails so an agent cannot take an action nobody can undo.

2. The build your client asked for and you do not want to hire for.

A document assistant with real citations. An intake-to-structured-data pipeline. An internal tool with auth and an admin view. An eval harness around a feature that already shipped. Scoped in writing before the first line of code.

3. The no-code chain you configured that has hit its ceiling.

Zapier, Make, or a stack of app integrations doing something it was never going to keep doing. Replaced with real code that does the same thing and keeps working, in their repository.

Limits

What we will not take, on any budget

  • Design, brand, content, SEO, and general web development. Those are yours, and a subcontractor who quietly expands into them becomes a competitor. If a scope you send has those in it, we quote only our part and say so.

  • A body billed by the hour for six weeks. There is no day rate here and no retainer that holds time for you. If what you need is capacity, we are the wrong supplier and will say so in the first reply rather than the fourth week.

  • A system that makes the final decision in a medical, legal, hiring, lending, or insurance context. We decline those, including through a partner.

  • Your client's production credentials before a scope is signed.

  • Anything we would be learning on your client's budget. Tell us the stack and we answer honestly before you pay for anything.

What we sell instead, and it is the whole reason this works as a subcontract.

Numbered deliverables, at a fixed price agreed in writing before anything starts, each one with a written acceptance criterion, which is a plain sentence saying what has to be true for that item to be done. You can lift those criteria straight into what you put in front of your client. That is why you can quote confidently, why a scope change is a new number rather than an argument, and why you are never carrying an open meter on our behalf.

How the relationship works

Four rules, and all four go in writing

1. Your client stays yours.

We do not contact your client without you, we do not market to them during or after the work, and for twelve months after an engagement ends we do not take direct work from a client you brought us. Two limits on that, stated here rather than buried, because a promise with hidden edges is worth less than a narrow one you can rely on: it covers clients you introduce in writing against a specific piece of work, not every company named in a conversation. And if a company is already a live prospect of ours, or approaches us independently, we tell you before we act on it rather than let you find out afterwards. That is the clause we will put in the subcontractor agreement, in those words.

2. We are invisible by default.

Our name appears nowhere your client sees unless you decide it should. Deliverables, documentation and code go to you in a form you can pass on under your own name. One reservation, and it is the only one: we may describe the work in anonymized, non-identifying terms, the shape of the problem and what we did, never your name or your client's, and you approve the wording before it is published anywhere. If you would rather we were named to your client instead, say so. Being introduced as a named specialist is fine by us and some partners find it helps them sell.

3. You set your client's price.

We quote you a fixed price for a defined scope. What you charge your client is your business, we do not ask, and we do not police it. You are carrying the client relationship and the risk of it, and the margin on that is yours.

4. One build at a time.

We will tell you what we can start and when, and we will tell you when we cannot take something. A subcontractor who says yes to everything is how your delivery date becomes a surprise.

Where to start

Most partnerships start with one small paid review

The lowest-risk way to find out whether we are any good is to give us one real thing and watch what comes back. Send a client's prototype or shipped feature. Five business days from access you get a written engineering review of one flow, written so you can forward it to your client under your own name. Reviews start at $500, and the exact price is agreed in writing before it starts. What starts the five days is read-only access and the exported prompts, not signature and not a kickoff call, which means you can commit to your client with a date you control.

The review comes first on a first job, and that is about the job rather than about you. Quoting a build on a system neither of us has read is how a fixed price becomes a fixed loss. After you have paid us once, the next piece of work does not need another review, including when it is for a different client of yours. What decides it is whether there is something to price against: your own written spec with acceptance criteria, or a codebase we have already worked in. With either in hand we quote the build directly. Without them we say so plainly and quote the scoped piece of work that produces something readable, rather than selling you the review again.

Sometimes the honest answer in a review is that the thing should not be built, or should be built much smaller. You get that in writing, and the review has still done its job. A subcontractor who never talks you out of a build is optimizing for their own invoice rather than your client's outcome.

Data boundary

How your client's data is handled

  • No client secrets, credentials, or confidential records through the form.Send the shape of the problem. The rest comes after paper.
  • NDA and subcontractor agreement, both signed, before client material moves.Non-solicitation of your clients belongs in it and we expect it to be there.
  • Their repository, their infrastructure.There is no PitTechs platform and nothing proprietary in the middle. If we disappeared tomorrow, your team or anyone else picks the work up from where it sits.
  • Read-only and scoped access,never admin credentials, and never before a scope is signed.
Objections

The questions a delivery lead actually asks

"Will you poach my client?"

No, and it goes in the subcontractor agreement rather than living only on this page: no direct approach to a client you introduce in writing, no marketing to them, and no direct work with them for twelve months after the engagement ends. Where it stops, so you are not relying on something we did not say: it covers clients introduced against a specific scope, not every company you mention to us, and if one of them is already a live prospect of ours or comes to us on their own, we will tell you before we do anything about it. Beyond the paper, it would be a bad trade: one partner who keeps sending us work is worth more than one client we took once.

"What does my client see?"

Whatever you decide. By default, nothing with our name on it. Deliverables and documentation are written to be forwarded under your brand. The single exception is that we may write about the work anonymously, problem shape and what we did, never your name or your client's, with your approval on the wording first. If you would rather introduce us as a named specialist, that works too and often makes the sale easier.

"Do you have agency references?"

Not yet, and we are not going to imply otherwise. PitTechs is new under this focus. That is precisely why the first step is the cheapest thing we sell and why the first engagement should be something you could absorb if it went badly.

"How does the money work?"

We invoice you, not your client. Fixed price for the agreed scope. A scope change produces a new quote you accept or refuse. There is no hourly meter and no invoice you have not already seen the number on.

"Do we have to buy a review every time?"

No. The review is how a first engagement starts. After that, what we need in order to quote a build is something to price against, not another review. Your written spec with acceptance criteria, or a codebase we have already worked in. Where there is genuinely nothing readable to price from, we say that and quote the scoped work that produces it.

Send us one scope and see what comes back.

If a client has asked you for something AI-shaped recently and you passed on it, that is usually the one worth sending.

Send us a client scope

Fixed price in writing before anything starts. You keep the client. We stay invisible unless you say otherwise.

No client secrets, credentials or confidential records through this form.