About
We built the rest of the team.
Capybari is a fully managed AI engineering organisation. Fourteen specialist roles plan, build, review, ship and investigate your software — on your repositories, on your servers, at whatever autonomy level you have earned the nerve for.
The reason
Code generation stopped being the bottleneck
Somewhere in the last couple of years, writing the code got easy. Ask for a function and you get a function. Ask for a feature and you get most of a feature. That problem is, for practical purposes, solved.
Nothing else moved.
The work that surrounds the code — deciding what to build, breaking it into tasks that do not collide, reviewing the diff, checking it for a security mistake, merging it, shipping it, watching the health check, putting it back when the health check fails, and working out at 3am why it failed — all of that is still done by a person. Usually the same person. Often the only person.
The stretched builder
We built Capybari for one reader in particular. You are a technical founder or the lead engineer at a company of somewhere between two and thirty people. You ship product. You also run the infrastructure. You also hold the pager. You also review your own team's code, when there is time, which there is not.
You cannot justify hiring a QA engineer and a security engineer and a DevOps engineer. You genuinely need all three. So you do what everyone does: you trade them against sleep. Review goes first. Then the security pass. Then the monitoring. Nobody decides this. It just happens, one busy fortnight at a time.
That is the gap. Not code. Everything around the code.
What we did about it
We did not build a better autocomplete. We built an organisation.
A Project Manager reads your request and writes a plan in plain English, with owners and a dependency graph. Specialists pick up tasks and build them, each on its own branch in its own git worktree, so parallel work cannot collide. A Code Reviewer and a Security Engineer can reject work, not merely produce it. A DevOps Engineer merges, deploys over SSH to a server you own, runs the health check you wrote, and runs your rollback command if the check fails. When a deploy goes wrong, an investigation opens with read-only access, works out the cause, and files the follow-up request itself.
You watch the whole thing on a board.
What we will not do
We will not tell you how many hours you saved, because we cannot measure that honestly. We will not put a compliance badge on the site that we have not earned. We will not hide behind a "contact sales" button on the Enterprise tier — we publish the list of what we are missing and roughly when we expect to have it, because we would rather lose a deal we could not serve than win it and disappoint someone in month three.
If you want the long version of that argument, it is on the pricing page, where it belongs.
Values
Five rules that decide arguments
These are not posters. Each one has settled a real product decision, and each one costs us something.
Show the work
Every plan, every diff, every deploy log and every investigation is visible on the board. An organisation you cannot observe is not one you can trust — which is why the product streams a run live rather than handing you a summary afterwards.
Gates before speed
Review, approval and rollback are not friction we are working to remove. They are the product. Any role can be marked as requiring human review, and when it is, dependent work stops at every autonomy level.
Calm under load
The interface gets quieter as things get more serious, never louder. A failed health check does not flash red at you; it rolls the deploy back, opens an investigation and tells you what it found.
Honest about the edges
We publish what we are bad at. The Enterprise tier lists the things we do not have — no completed SOC 2 audit, no identity-provider-grade SSO, no contractual uptime SLA — instead of offering you a sales call.
Your infrastructure, your code
We work on branches inside your repositories and deploy to servers you control, using a deploy command you wrote. There is no lock-in by hostage-taking. Leaving should cost you an afternoon, not a quarter.
The name
Why a capybara
Choosing a mascot is usually the least serious decision a company makes. This one is load-bearing.
The animal
The calmest thing on four legs
A capybara is famously unbothered. It sits in genuinely chaotic situations and declines to participate. It gets on with every other species that turns up. Birds sit on it. It does not mind.
- Unbothered is a skill — it is not indifference. The animal is alert and entirely aware of what is going on around it. It has simply decided not to panic about any of it.
- It gets along with everything — our product has to sit inside your stack, your git host and your deploy process without demanding that any of them change.
- It has no first name — it is the Capybari capybara. Resisting the urge to name it is the most restrained thing we have ever done.
The idea
Calm is the feature
Shipping to production is the most anxiety-producing thing in our customers' working week. Every competitor sells speed. Speed is table stakes, and on its own it is frightening: shipping faster without gates is just breaking faster.
- Calm is not slow — tasks run in parallel across isolated worktrees. Calm is what you feel afterwards, not a speed limit.
- Calm is a list of mechanisms — a review gate, an isolated branch, a health check, a rollback command, and someone looking at the logs. The product genuinely has all five.
- We sell what is underneath the speed — the board going quiet at the end of a deploy is the entire product. Everything else is how we get there.
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
What is in the box
Product facts, not projections
Every number below describes something you can use today.
We publish no customer counts, no revenue figures and no velocity multipliers. When we have a number worth stating, we will show you the method behind it. See the public roadmap.
How we work
The company runs on the same rules as the product
If a gate is good enough to sell, it is good enough to live under.
Write it down first
Review is not optional here either
Remote, written, asynchronous
Publish the gaps
No dark patterns, written down as a rule
One primary action
History
A short company with a specific list of things it has done
We are new. Rather than dress that up, here is everything, in order.
Capybari starts as an internal tool
Built to solve our own problem: too much roadmap, not enough people to review it. PLACEHOLDER — confirm the founding month and the founding team.
The role contracts are written
Fourteen specialist roles, each defined by a Markdown document setting out what it owns and where it must stop.
Isolated worktrees ship
Every task moves onto its own branch in its own git worktree. Parallel work stops colliding.
Review gates and autonomy levels ship
Manual, Supervised and Autonomous, plus requires_review on any role — the first version anyone outside the team was allowed near.
Deployment targets, health checks and rollback
Connect an SSH host, supply a deploy command, a health check and a rollback command. A failed check restores the last healthy commit.
Production investigations ship
A failed deploy opens an investigation with read-only access. It writes up the cause and opens the follow-up request itself.
One project, real gates, no card
The free plan includes three core roles, one repository and Manual autonomy — the whole pipeline, at the level where nothing runs until you press the button.
Live run streaming and design previews
Watch the commands a task runs as it runs them, and share a preview link for front-end work before anything merges.
Start with one request
Connect a repository, file the thing that has been on your list for a month, and read the plan that comes back. Manual autonomy. Nothing runs without you.
No card required · Free plan forever · Export everything, any time