Customers
Teams who stopped
doing all of it themselves
Small companies, mostly. A handful of engineers, or none at all. What they have in common is a pipeline they could describe but never staff — and a strong preference for finding out about a bad deploy from a rollback log rather than a customer.
Building on Capybari
These companies are invented. They are placeholders for a real logo wall, and we would rather say so than inflate one. See case studies for the same disclosure in full.
What everyone gets
The same organisation, on every plan that includes it
Numbers about the product, not about our funnel. We publish no customer counts until we can show you how they were counted.
No customer counts, no revenue figures, no velocity multipliers. When we have numbers worth quoting, they will arrive with the method attached — as they do in the case studies.
In their words
Six teams, six different first requests
Every quote below is written by us, about companies that do not exist. They illustrate the kinds of change teams describe. They are not evidence, and we will not present them as evidence.
We moved from Manual to Autonomous over about a month. What convinced me was not a feature — it was watching a bad deploy roll back at 2am and the investigation already open when I woke up.
I am not an engineer. I file requests in the same language I would use with a contractor, and I get a plan back that I can read before anything is allowed to happen.
The reviewer catches what our juniors used to ship. A security pass on every request stopped feeling like an overhead the week it found a card number sitting in our logs.
Eleven client projects, each with its own team and its own deployment target. When a client asks what changed last week I forward the reports rather than write a summary on a Sunday.
Our warehouse tool was written by a contractor in 2021 and nobody here had opened it since. It got read, planned and changed without any of us having to pretend we understood it first.
The part I did not expect to like is the agent stopping to ask a question. Twice it asked something our own onboarding document should have answered, and we fixed the document.
Full write-ups, with methods and the parts that went badly, are in our case studies.
Case studies
Three of them at length
Each one states how its numbers were measured and includes something that went wrong. A case study with no bad week in it is a brochure.
Tilltap
A four-person shop that spent eleven weeks earning its own trust, one autonomy level at a time — including the deploy that rolled back at 2am.
Read the studyOrderly Health
A founder who cannot read a diff, running admin tooling on plain-English plans, approval gates and design previews. Two plans were rejected outright.
Read the studyNorthwind Freight
A dispatch system nobody had opened since its author left, a security pass that found something ugly, and a first plan that was simply wrong.
Read the studyThe pattern
What these teams have in common
They are in different industries and different countries, and they arrived for different reasons. Three things repeat anyway.
One
They all started at Manual
Not one of them connected a production server in week one. They filed a request, read the plan, and looked at the diff — with nothing able to run until they pressed the button.
- Autonomy is earned, not configured — Manual approves everything. Supervised plans on its own and dispatches work you have approved. Autonomous lets healthy work ship without you.
- The gates never go away — Any role flagged as requiring review stops dependent work at every autonomy level, including the highest one.
- Nobody moved up on our timetable — Each team changed level when its own plans stopped surprising it. We have no idea how to hurry that and would not try.
Two
They all kept their own infrastructure
Every one of them deploys to servers they already had, into repositories they already owned. A deployment target is an SSH host with commands they wrote themselves.
- Your git remotes — Work happens on branches inside your repository. There is no copy of your codebase living somewhere you cannot reach.
- Your deploy command — Capybari runs the command you already use, then the health check you already trust, then your rollback command if the check fails.
- Leaving is a normal Tuesday — Stop paying us and you keep the branches, the merge history and every structured report. There is nothing of yours to hand back.
Merged 4 branches, no conflicts
Deployed to prod-web-1 over SSH
Health check failed — /healthz returned 503 twice
Rolled back to a3f91c2 — the last commit known healthy
Investigation INV-11 opened automatically
Three
They all had something nobody wanted to touch
A payment integration. A dispatch system. A billing screen written in a hurry. Every one of these teams had a corner of their product that had quietly become nobody's job.
- Read first, plan second — The Project Manager reads the connected repositories before writing a plan, and returns it in plain English with owners and dependencies.
- Cheap to be wrong — Each task is a branch in its own worktree. An approach that turns out badly is abandoned, not unpicked.
- It asks — A specialist that hits genuine ambiguity pauses the run and puts the question to a human instead of choosing for you.
T-02 task/t-02-auth-migration → .worktrees/t-02
T-04 task/t-04-sca-challenge → .worktrees/t-04
T-05 task/t-05-challenge-modal → .worktrees/t-05
Add your name to a wall we have not inflated
Connect a repository, file one request, and see what the plan looks like before you decide anything. Manual autonomy, no card, and every branch stays yours.
No card required · Free plan forever · Export everything, any time