Solutions
Find your team on this page
Capybari runs the same pipeline for everyone. A request gets planned, specialists build it on isolated branches, review gates sign it off, and it deploys to your servers with a health check and a rollback command. What changes between these four teams is which part of that you were doing yourself, at midnight, on your own.
Four ways in
Same gates.
Four reasons to want them.
Nothing below is a different product. It is the same board, the same fourteen roles and the same deployment pipeline, described from where you are standing.
Startups
Ship the roadmap you could not staff
You have a roadmap sized for twelve people and a team of three. Nobody decided to stop reviewing code — it is just what is left after the sprint. Review goes first, then the security pass, then anything resembling monitoring.
- Roles you cannot justify hiring — Add a Security Engineer, a QA Engineer and a DevOps Engineer to a project because a request needs them, not because you raised a round.
- Parallel without collisions — Every task runs on its own branch in its own git worktree, so three specialists build at once and none of them can see another's half-finished work.
- A deploy that fails safely — Give a deployment target a deploy command, a health check and a rollback command. A failed check restores the last healthy commit and opens an investigation.
- Trust you turn up slowly — Start at Manual, where nothing runs until you press the button. Move to Supervised, then Autonomous, when the plans stop surprising you.
Agencies and studios
Run more client projects than you have people
Utilisation is the business, and context-switching is what eats it. Senior time disappears into work a junior could do, three clients want a status update on the same Thursday, and the fourth wants to know why the invoice went up.
- One project per client — Separate repositories, a separate team of agent profiles and separate deployment targets. Nothing crosses between engagements.
- An audit trail you can hand over — Every task ends in a structured report — summary, files modified, risks, assumptions, recommendations, blockers. That is your Thursday status update, already written.
- Substitution you can see — If a client's project has no Database Engineer on its team, the work is reassigned to whoever can cover it and the substitution is recorded rather than quietly absorbed.
- Per-project cost control — Model and effort overrides sit at project and request level, so a fixed-price retainer and an exploratory build do not have to cost the same.
Internal tools
Maintain the systems nobody owns
The rota tool. The invoicing thing. The dashboard finance runs on, written by someone who left two years ago. It belongs to nobody until it breaks, at which point it belongs to whoever is nearest.
- Planned against your actual code — The Project Manager reads the connected repositories before it writes anything, then hands back a plain-English plan with owners and a dependency graph.
- Smallest safe change — Role contracts are Markdown files you can read and edit. The shipped ones tell every specialist to reuse existing patterns rather than introduce new ones.
- Nothing merges quietly — Flag any role as requiring review and everything downstream stops until a human approves it — at every autonomy level, with no exceptions.
- Questions instead of guesses — When a specialist hits genuine ambiguity in an undocumented system, it pauses the run and asks you, rather than picking an answer.
## Responsibilities
- Verify the change is the smallest one that satisfies the task
- Reject unrelated modifications
- Confirm tests cover the new behaviour
## Limits
- Never implement the fix yourself — return it to the author
Non-technical founders
Own your product without an engineering team
You are waiting on somebody else's calendar for changes to your own product. Every small fix becomes a quote, then a scoping call, then three weeks, then an invoice with a line item you cannot check.
- File it in plain English — One sentence is enough. "Customers in Ireland cannot pick a delivery slot." Set a type and a priority; the Project Manager writes the plan.
- Approve before anything happens — At Manual autonomy nothing dispatches until you press the button. You read the plan first, in language you can actually check.
- Look at it before it ships — Front-end tasks produce a shareable design preview link, so you and anyone else can see the screen before a single branch merges.
- Talk to the manager — Discuss a project with the Project Manager in conversation, and turn that conversation into a request when you are ready.
Shareable link, expires with the task. No deploy required.
Where this lands hardest
Eight situations that keep turning up
Not a list of verticals we would like to sell to. These are the shapes of work where a review gate, an isolated branch and a rollback command are worth the most.
Internal tools
Line-of-business apps that are invisible for eleven months and business-critical on the twelfth.
SaaS before a Series A
More roadmap than engineers, and a review process that currently exists as a shared intention.
E-commerce and marketplaces
Checkout changes nobody wants to try on a Friday, and a rollback command that has never actually been run.
Fintech back-office
Ledgers, reconciliation and admin screens, where a quiet mistake is expensive and a security pass on every request is not a luxury.
Agencies and studios
Many clients, one senior engineer, and a utilisation figure that never survives contact with a context switch.
Logistics and field service
Dispatch, routing and driver tooling, where the people waiting on a fix are somewhere on a motorway.
Healthtech admin
Scheduling, billing and back-office work only. Nothing clinical, nothing anywhere near a decision about a patient.
Codebases with no author
The repository everyone is slightly afraid of. Isolated branches make a wrong turn cheap to throw away.
In practice
Three teams, three reasons
We are four engineers with a roadmap for twelve. The change was not speed — it was that the security pass stopped being the thing we promised to do next quarter.
Every client project has its own team and its own deployment target. When a client asks what happened last week, I send them the reports instead of writing a summary on a Sunday.
Our warehouse tool was written by a contractor in 2021 and nobody here had opened it since. It got planned, changed and reviewed without any of us pretending to understand it first.
Every quote and company on this page is invented while we collect real ones. The case studies say so at the top, and show the method behind each number.
Objections
The question your segment actually asks
We are three engineers. Does this just create more review work for us?
You decide where the human sits. Any role can be flagged as requiring review, and only work behind that flag waits for you. Everything else runs to a structured report you read when it suits.
Most small teams start with review on the Code Reviewer and Security Engineer, then relax it once they have watched a few requests go through untouched.
Our clients own their repositories. Can an agency still use it?
Yes. A project connects to git remotes you have access to and works on branches inside those repositories — not on a copy in ours. Each client is a separate project with its own team of agent profiles and its own deployment targets.
If a client later takes the work in-house, the branches, the history and the reports are already theirs.
The system I need help with is old and badly documented. Is that a problem?
It is the normal case. The Project Manager reads the connected repository before it plans, and role contracts instruct specialists to make the smallest safe change and reuse existing patterns.
When a specialist hits real ambiguity it stops and asks you a question mid-run instead of guessing. And because every task lives on its own branch, a bad direction costs you a deleted branch.
I cannot read code. How do I know the plan is right?
You read the plan, not the code. It comes back in plain English: one task per piece of work, an owner on each, and the order they have to happen in.
At Manual autonomy nothing runs until you approve. Front-end tasks produce a shareable design preview link, so you can look at the actual screen before anything merges.
Can I run several client projects without them touching each other?
Projects are separate: separate repositories, separate teams, separate deployment targets, separate boards. An agent working on one client's task has that project's repositories and nothing else.
We are pre-revenue. Is there a version we can afford?
The Free plan gives you one project, one repository, three core roles, Manual autonomy and 100 agent runs a month, with no card. It is enough to file a real request and read a real plan. See pricing for where it stops.
What if we need a role you do not have?
Every role's behaviour is a Markdown contract you can edit, and on the Pro plan you can write your own. If a project's team is missing a role a plan calls for, capability substitution reassigns that work to whoever can cover it and records what it did.
Do we have to give it our production servers?
No. A deployment target is optional. Plenty of teams run Capybari for planning, building and review only, and merge or deploy by hand.
If you do connect one, it is an SSH host you define, with a deploy command, a health check, a diagnostics command and a rollback command that you write. The security page sets out the rest.
Your situation not on the list? Describe it to us — a person replies.
Start with the request you keep postponing
Connect one repository, file the thing that has been sitting on your list since March, and read the plan that comes back. Manual autonomy. Nothing runs without you.
No card required · Free plan forever · Export everything, any time