A small software studio

AI that survives contact with production.

Most AI consulting ends at a pilot. We take on the work that excites us, build it ourselves, and run it like it matters — AI integration and enablement, development operations, and platform work for technical businesses, on infrastructure you own at the end of it.

What we do

Seven ways in, one standard of work.

Engagements are scoped to a deliverable and a handover, not to a discovery phase. Whichever door you come through, you end up owning the result.

Build

AI integration

Agents, LLM features, retrieval and evaluation shipped into a product that already has users. We work inside your codebase, your review process and your deploy pipeline — not alongside them in a prototype repo.

Enable

AI enablement

Getting your engineers genuinely faster with agent-driven workflows: the tooling, the context files, the review discipline, and the gates that make it safe to let an agent write code that reaches production.

Govern

Training & governance

Practical training for technical teams, and the governance layer underneath it — what agents may touch, what always needs a human, how access is scoped, and how any of it is audited after the fact.

Ship

Software development

Contract engineering across product, platform and infrastructure. Built to be handed over: documented, tested, and deployable by someone who wasn't in the room when we wrote it.

Operate

Development operations

Everything between a merged branch and a running system: CI, staged environments that actually match, infrastructure as code, observability, the integrations wiring your systems to each other — and the cloud account itself, on AWS, GCP or your own metal: what runs in it, what it costs and who can reach it. Rollback in one command; a deploy should be a non-event.

Own

Fractional CTO & platform

Ongoing technical ownership for teams without a senior engineering voice: architecture calls, build-versus-buy, what to hire for next — and standing behind those decisions once they are load-bearing.

Direct

Technology management

The business side of the stack: what you run, what it costs, what it's actually for, and what to retire. Vendor and build/buy calls made against your numbers rather than a category quadrant.

A package, not a project

The whole operating stack for a technical startup — open source, self-hosted, yours.

Every early-stage company reassembles the same set of tools, and rents most of them. We install the open-source equivalent as one coherent estate: version control through to backups, on infrastructure you choose — your cloud account or your own metal — with no per-seat pricing and no vendor holding your history.

It comes wired for agents from day one — a control plane your AI tooling can operate the business through, on the same audited path a person uses.

  • CodeGit hosting, CI runners and a private container registry
  • PlanProject and issue tracking, linked to the code it describes
  • ObserveLogs, metrics and dashboards across every host and service
  • RunContainer orchestration, automatic TLS, staged environments
  • ProtectSecrets management, encrypted off-box backups, private mesh networking
  • AutomateAn MCP control plane so agents can query, deploy and report

Plain english

What an MCP control plane is, and why you want one.

We use the term twice above, so here it is without the jargon.

MCP is the Model Context Protocol — an open standard for connecting AI assistants to real systems. Anthropic published it in 2024 and it has become the common way agent tooling talks to the outside world. Rather than writing bespoke glue for every assistant against every tool, a system exposes an MCP server: a named set of operations the assistant may call, and data it may read, over one protocol.

The hard part of AI integration was never the model. It is reach — what your agents may touch, on whose authority, and what is written down afterwards. Hand an assistant a database credential and you have given it everything that credential can do, with no record of what it did. Most stalled AI pilots stall exactly here, and no amount of prompting fixes it.

A control plane is where that boundary goes: one place that decides which operations exist at all, checks who is asking before each one, and logs the answer. Build it once and it becomes the reviewable artifact — you can read it and know precisely what your agents can and cannot do. Wire each integration separately and no such document exists.

This is a thing we build. Centralis, below, is ours.

One call, end to end

  1. The agent asks for an operation Not "access the database" — a specific named tool the server chose to expose, with typed arguments.
  2. The server checks who is asking Each caller has its own identity and its own scope. A tool that is not granted does not appear at all.
  3. The operation runs under its own limits Read-only stays read-only. The agent never holds the credential; the server does.
  4. The call is written down Who called what, with which arguments, and what came back — before anyone has to ask.
  5. Structured data goes back Records the agent can reason about, not a screenshot it has to guess at.

What we run

We don't recommend systems we haven't operated.

Jinemi builds and runs its own products. The practices we sell are the ones keeping these online.

Thermograph

Public product · live since July 2026

A free service that grades how unusual the weather is at any point on Earth — as a percentile against roughly 45 years of that exact location's own climate history, not a thermometer reading.

Behind it: a multi-terabyte climate data lake we host ourselves, a time-series database, three environments on separate machines, and continuous promotion from branch to production. No managed database, no SaaS forge, no per-seat CI bill.

Centralis

Internal platform · in production

An MCP control plane over the entire estate. One server through which an AI agent can query the production database read-only, search the logs, drive the forge, check fleet health and run a deploy — each call authenticated, scoped and written to an audit trail.

Not a demo. The same server answers questions about the application database, tails logs across every host, opens and merges pull requests, checks whether last night's backup actually landed, and runs deploys — each through a tool that had to be deliberately written and scoped before it existed at all.

Kylene

Internal tool · built in-house

Meeting capture for voice channels: per-speaker transcription, then a written summary filed where the team already works, with a durable copy archived to shared storage.

We priced the SaaS option at a flat $20 per month and built the replacement instead — it costs roughly three cents per hour of conversation, because capture is gated on who is actually speaking. The interesting number isn't the saving; it's that there is no configuration of it that produces a surprising bill.

How we work

What you can hold us to.

Only what excites us

Excitement is the project filter — if nobody here is excited by it, we say no. That reads like a luxury and is actually the quality control: work nobody wanted is the work that quietly rots. You get a team that chose you.

Everything is a pull request

Humans and agents go through the same door: branch, review, required checks, explicit merge. Nothing reaches an environment any other way. It is the single practice that makes agent-written code safe to ship.

Cloud-agnostic, and you own the stack

We have no vendor allegiance to sell you. We work across AWS, GCP and bare metal, and build on the primitives all of them share — containers, object storage, DNS — so changing provider is a migration rather than a rewrite. We have done exactly that with our own production estate. Where a managed service genuinely wins we'll say so. You should be able to fire us and keep running.

Reliability over flash

Anything clever proves itself on a lower environment first. Production receives changes that have already been observed working somewhere else, and every deploy has a rollback that takes one command.

We treat it as our own

Everyone here acts like an owner of the thing being built — of quality, of the outcome, and of the person who has to use it. That is why the handover documentation exists before you ask for it.

You keep the keys

Credentials, domains and accounts stay in your name throughout. We work under scoped, revocable access that you can withdraw in a single line — during the engagement, not just at the end of it.

Start a conversation

Tell us what's stuck.

A short, specific email gets a substantive reply — usually with an opinion attached, whether or not there's an engagement in it. If we're the wrong people for the problem we'll say so early.

hello@jinemi.com

Useful things to include

  • What you're building, and who it's for
  • Where AI is supposed to fit — or where a pilot stalled
  • What your deploy process looks like today
  • Team size, and who owns infrastructure
  • Whether you're after a build, a retainer, or a second opinion