Offerings

How the work is packaged.

The homepage describes three ways in — build, enable, operate. This page is the commercial shape underneath them: where the work runs, who owns what, and how you pay. It is the same standard of work whichever door you come through.

There is no price list on this page, and that is a position rather than an omission. The price of this work follows what you actually need — how many systems are being connected, where they run, who operates them afterwards — so a published menu would be published fiction. What we publish instead is the shape of every engagement. The number arrives as a written quote after a scoping conversation, and the conversation costs nothing.

Call us See what we run

The four decisions

Taken in order, because they constrain each other.

One workload characteristic forces a commercial decision, and that decision narrows the next. Taking them out of order is how projects get re-architected in month three.

What runs where Elastic, bursty, user-facing work goes to cloud, because you cannot buy a rack fast enough for a traffic spike. Steady, hardware-bound work — model serving, the control plane, databases — runs on provisioned infrastructure, because sustained load on rented compute costs several times what owning it does. Most estates are a split rather than a choice, and we size the split against your actual traffic during scoping.
Whose provisioned infra Ours is the default and the fastest start: you provision nothing, and your environment is dedicated to you, never shared. Yours makes sense when you already have capacity, a data-residency rule, or an air-gap requirement. Either way, who patches the hosts and who holds the pager is agreed in the statement of work, not assumed.
Who owns the cloud account We hold it by default so you have nothing to set up — one account per client, never shared, with a hard spend cap set at the provider. Anything that scales with your customers rather than your staff should be yours from day one, and we will say so when we see it. Wherever it starts, the account is transferable to you at any point, in writing.
Which API vendor Open choice — Anthropic, OpenAI, Google, xAI, or open weights you host yourself — routed through one gateway, so this is the one decision of the four you can reverse cheaply. Pick on compliance, model availability, and agreements you already hold. One coupling is worth knowing: private networking to a vendor lives in a cloud account, so a security review that has ruled out public endpoints has effectively made decision three for you.

Standard setups

Four shapes we build most often.

The decisions above produce more combinations than anyone wants on a menu. These are the starting points — treat them as shapes rather than a fixed list, because most engagements are one of these with the details moved.

A · Our infra, our cloud account, we manage

Turnkey

For organisations with no infrastructure function and no elastic-scaling workload. You sign one contract and nothing else.

Provisioned components on Jinemi hardware, dedicated to you
Cloud components in a Jinemi-held account — capped, and transferable to you on request
API vendors on public endpoints under enterprise terms
Nothing for you to provision, rack, or refresh

B · Our infra, your cloud account, we manage

Split

For a scaling app tier with no appetite to run GPUs or a gateway. The most common shape we build.

Cloud components in your account — your quotas, your invoice
Model serving and the control plane on Jinemi hardware
Private networking to Bedrock or Azure available, since the account is yours
We operate both sides; you keep the provider relationship

C · Your infra, your cloud account, management scoped

In your estate

For existing capacity, a residency rule, or an air-gap requirement. Nothing of yours sits on our hardware.

All provisioned components on your infrastructure
Management split layer by layer in the statement of work
Strongest compliance posture — no third party in the data path
The longest build, because your estate is not our standard stack

D · Any placement, you operate

Build & hand over

For teams that already have a platform function and want the build, not the babysitting.

Any of the placements above, built and proved against your real systems
Runbooks written for an engineer who was not in the room
Architecture and decision records, and a demonstrated restore
Our access revoked at handover, unless you attach a care retainer

Identical in all four

What every setup carries.

Placement changes where the work runs. It does not change what arrives with it — these are the same in every setup, because they are the parts that make the rest governable.

Control planeThe MCP layer from the homepage: scoped tools, identity on every call, reads that cannot write, writes that stop at a human gate, everything audited
DashboardYou watch it, not us — spend against your cap, where requests route, and what the platform costs against the alternative
CapsYou set a monthly spend ceiling; we alert as you approach it and stop when you reach it. Where we hold the cloud account, the cap is set at the provider, not only in a dashboard
EnablementRole playbooks and training for the people who will live with the system
RunbooksDocumentation written while the thing is being built, deployable by someone who was not in the room

The boundary itself — why agent access needs a control plane at all, and what it buys you — is explained on the homepage.

Non-negotiable

The one thing we ask for.

A named system owner, on your payroll, with real authority. Someone who can grant and revoke access, approve production releases, and answer a question within a working day. Not a committee, and not a project manager relaying to someone else.

It is typically around two hours a week — more during the build, settling afterwards — and we ask for a named deputy at kickoff so leave and turnover do not stop the system. This is the one requirement we will not waive, and it is not bureaucratic: an engagement where nobody on your side can approve anything stalls at the first access request and stays stalled. We can recommend, build and operate. We cannot approve our own access to your systems, and we will not ask to.

How you pay

Four commercial shapes, no menu prices.

What sits in your name is billed to you by the provider at their price — we never mark it up. What sits in ours is billed by us, with the structure visible. Beyond that, how you pay follows which setup you chose and how much of it you want us to carry.

The usual answer

Build, then managed

A fixed-fee build, then a managed retainer while your team grows into it, then handover if and when you want it. Operation, monitoring, incident response, and an allowance of change work each month.

Setup D

Care retainer

You run it; we stay reachable. Bug fixes, dependency and model migrations, a few hours a month. No on-call.

Any setup

Per project

Scoped and quoted per piece of work. No reserved capacity, so lead time is typically a few weeks.

At renewal

Changeable

The commercial shape is revisited at every renewal — including whether you still need us at all. We would rather you outgrew us.

Add-ons

Bolted onto any setup.

MCP integrationOne more system behind the control plane — a REST API or common SaaS tool, or an enterprise platform with a real permission model
Custom skill or agentOne real job, packaged and tested, with its own review gates
Enablement programmeRole playbooks, champion training, and an adoption check-in
Compliance hardeningControl mapping and evidence for SOC 2, HIPAA, or equivalents
Readiness assessmentA few weeks, only when the picture is unclear — and credited in full against a subsequent build
Fractional technical leadershipSenior ownership across the wider estate, not only the AI work

How it starts

Two free steps, then a fixed scope.

A call Sixty to ninety minutes, no charge. What you want AI to do, what it would touch, and your real constraints.
A written recommendation Within a week: which setup, why, the risks we can see, and an indicative price. Also free.
A readiness assessment, sometimes Only when the picture is unclear. Credited in full against a build if you proceed.
A statement of work Fixed scope, fixed fee, named deliverables — and your named system owner.

From there, delivery is the sequence on the homepage: built in your system, reviewed as pull requests, handed over with runbooks.

Fixed points

What carries across every engagement.

Always

Everything is a pull request — humans and agents pass the same gates
Access is scoped and revocable, and we document what we hold and why
Runbooks and documentation ship with the build, not after it
Reliability over flash — production should be boring
You can leave: exit is a handover process we have already written down

Never

An engagement without a named system owner on your side
An agent that can change production without a human gate
Staff augmentation by the seat — we deliver scoped outcomes
Hardware sold to you where a cloud account answers the question better

Start a conversation

Call us.

The call and the written recommendation cost nothing, and if we are the wrong people for the problem we will say so early — and point you somewhere better.

Useful to include: roughly which setup fits, what you want AI to touch, and the constraints that shape it — compliance, residency, agreements you already hold.

hi@jinemi.com

Good reasons to write

An AI pilot that works in a demo and cannot get to production
A scaling app that needs a control plane and nobody to run it
A residency or air-gap rule that says the work stays on your hardware
A platform team that wants the build and the runbooks, not a vendor
A nonprofit — contributory work, case by case