A software and AI engineering studio
Jinemi is a small studio. We build AI into products that already have users, write the software around it, and run the engineering underneath — agent access and governance, development workflows, CI/CD, observability and production operations.
The model is rarely the hard part. What an agent may touch, who reviews its work, how code reaches production, what gets written down afterwards — that is where AI pilots stall, and that is the work we do. Inside your systems, through your review process, and handed over so you can run it without us.
Why people call us
Almost every engagement starts as a version of one of these. Each is a problem we will take responsibility for, not advise you about.
“We have an AI prototype and no idea how to put it in front of real users without something going wrong.”
We take it the rest of the way — real data, scoped access, a review path, and a way to switch it off.
“Our engineers all use AI, but everyone does it differently and nobody is really reviewing the output.”
One workflow, with gates: the tooling, the context, and the review that makes agent-written code safe to merge.
“We want agents to reach our systems, and nobody is willing to hand them credentials to do it.”
We build the boundary — named operations, per-caller scope, credentials held server-side, every call recorded.
“The software works. Deploying it and operating it is the part everyone is afraid of.”
Infrastructure that grew by accident, made deliberate: CI, environments that match, observability, one-command rollback.
“We need someone senior owning the technical decisions, and we are not ready to hire a CTO.”
Architecture calls, build-versus-buy, what to hire next — and standing behind those decisions once they are load-bearing.
“We need this built, and we need to still own it after whoever built it has gone.”
Contract engineering across product, platform and infrastructure — documented, tested, and deployable by someone who was not in the room.
What we do
Most clients need one of these paths. Some need all three, in this order. Each is scoped to a deliverable and a handover — and whichever door you come through, you end up owning the result.
Build & integrate
AI features, and the software around them, shipped into a product that already has users. We work in your codebase, your review process and your deploy pipeline — what you get at the end is a running feature, not a prototype in a repository of its own.
Includes AI integration · LLM and agent features · retrieval and evaluation where they earn their place · product and platform engineering · internal tools · APIs and integrations
Enable & govern
Getting your engineers genuinely faster with agents, without creating something security will refuse to sign off. The workflow, the boundaries around it, and the evidence that those boundaries hold when someone asks.
Includes AI enablement for technical teams · agent-assisted development workflows · access boundaries and scoped credentials · human review gates · auditability · context and tooling design · training
Operate & hand over
Everything between a merged branch and a running system — and then out of your way. We can carry it while it is being built and still leave you able to operate it without us, which is the only version of this that counts.
Includes DevOps and CI/CD · infrastructure and environment design · observability · secrets and access patterns · cloud and account architecture · fractional CTO and technology management · documentation, runbooks and handover
The difficult part
This is where AI projects stop, and it is not a model problem. Give an assistant a database password and you have given it everything that password can do, with no record of what it did. Nobody signs that off, so the pilot stays a pilot.
The fix is a boundary with a name. One place that decides which operations exist at all, checks who is asking before each one, holds the credentials itself so the agent never does, and writes down what happened. Build it once and it becomes something you can read — a document of exactly what your agents can and cannot reach. Wire each integration separately and no such document exists.
We build these, and we run one. Centralis is ours: a single server through which an agent can query the production database read-only, search logs across every host, open and merge pull requests, check whether last night's backup landed, and run a deploy. Reads execute as a database role that is not permitted to write, so a stray update is refused by the database rather than by good intentions. Every change is appended to an audit log against the identity that made it. Releasing to production is the one thing the tooling prepares and recommends but never does — that stays a person's decision.
The mechanism is MCP — the Model Context Protocol, an open standard published by Anthropic in 2024 for connecting AI assistants to real systems. It matters commercially for one reason: it turns the boundary into a single reviewable thing, instead of glue code scattered across five integrations that nobody can audit together.
What the boundary buys you
The startup operating stack
A development and operating platform for technical teams who would rather not assemble their engineering stack one subscription at a time. Every company reaches for the same set — git hosting, CI, a registry, issue tracking, dashboards, secrets, backups — and rents most of it. We install the open-source equivalent as one coherent system, on infrastructure you choose: your cloud account or your own metal. No per-seat pricing, and no vendor holding your history.
It is built for people and for agents from the first day — a control plane your AI tooling operates the business through, on the same audited path a person uses. It is yours at the end, and it is the stack we run ourselves.
The commercial shape of all this — where it runs, who owns what, and how you pay — is on the offerings page.
Our own work
All three are ours — designed, written and operated here. They are not client case studies and not borrowed logos, and being straight about that matters more to us than a wall of them would. Each one is here because it proves something specific.
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 climate archive we host ourselves, as our own object storage and table format rather than someone else's API; a time-series database; a separate machine per environment; and continuous promotion from branch to production. No managed database, no SaaS forge, no per-seat CI bill. No tracking cookies and no per-visitor identifiers either — that was cheap to build in and would have been expensive to retrofit.
And it is run the way we sell: monitoring the app, managing migrations and failures, and the cloud and server administration behind the service all go through Centralis, our own MCP control plane — reads under a database role that cannot write, deploys prepared by the tooling and approved by a person.
Proves production software engineering · data infrastructure and APIs · staged environments · observability · privacy-first operation · agent-operated production · running a real public service
The control plane described above, in production. It is how Jinemi is operated day to day: an agent reaches the application database, the climate archive, fleet logs, dashboards, the code forge and deploys through one authenticated endpoint instead of holding six credentials.
Not a demo and not a reference implementation. Every operation it exposes had to be deliberately written and scoped before it existed at all, which is exactly the property that makes it reviewable — and it is why we can describe this problem from having solved it rather than from having read about it.
Proves agent integration · control-plane engineering · scoped system access · governance and auditability · operational automation · infrastructure integration
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.
It costs about three cents per hour of conversation, because capture is gated on who is actually speaking rather than running continuously. The point is not the unit price — it is that the cost is predictable by construction. There is no configuration of it that produces a surprising bill.
Proves practical AI workflow automation · speech and transcription pipelines · structured knowledge capture · cost-conscious system design
Company values
We would rather be corrected than be right later. Anyone here can tell anyone else that a decision is wrong, regardless of who made it, and the expectation is that the view actually changes.
High standards on the things that carry weight, and a bias toward finishing. Perfectionism is mostly a way of not shipping, and unshipped work helps nobody.
How we work
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.
Credentials, domains and cloud accounts stay in your name throughout. We work under scoped, revocable access you can withdraw in a single line — during the engagement, not just at the end of it.
Documentation and runbooks get written while the thing is being built, not assembled in the last week. The test is whether someone who was not in the room can deploy it, and we would rather find that out while we are still around to fix the answer.
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 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.
If nobody here is interested in the work, we say no. That reads like a luxury and is actually the quality control: work nobody cared about is the work that quietly turns mediocre. You get a team that chose you rather than a team with capacity to fill.
About us
Jinemi is a four-person studio. Between us we cover engineering, operations and product; business and growth; development; and QA, testing and project support. Nobody here manages people who manage people.
Small is the choice rather than the circumstance. It means the person who scoped your engagement is in the pull requests, a decision takes a conversation instead of a process, and we can say plainly what we do not do.
We build our own products and take on outside work in the same disciplines. That is why the practices on this page are described from running them rather than from a methodology deck.
One clarification
We are not affiliated with Gemini. Jinemi is an independent studio with no connection to Google, to Google Gemini, or to any of their products. The names look alike; that is the whole story. If you arrived here looking for Gemini, you want gemini.google.com.
How an engagement runs
Six steps, each scoped to something you receive, and you can stop after any of them. There is no discovery phase you pay for before we can tell you whether the project makes sense.
Start a conversation
A short, specific email gets a substantive reply — usually with an opinion attached, whether or not there is an engagement in it. If we are the wrong people for the problem we will say so early.
Useful to include: what you are building, what your deploy process looks like today, and whether you are after a build, a retainer or a second opinion.
hi@jinemi.comGood reasons to write