# Capybari > Capybari keeps building the software you already have. Give Capy your codebase, say what you want changed, and approve the plan before anything ships — on your repositories, on your servers. The full text of every public page on this site, in one file. The index of the same pages is at https://capybari.com/llms.txt. --- # Home URL: https://capybari.com/ You have a product and nobody reliable to keep building it. Give Capy your codebase, say what you want changed, and approve the plan before anything ships. ## Your code works. You just don't trust it anymore. Works on the code you already have You approve every change Your repositories, your servers ## What Capy is You built the product. Now who's going to keep building it? Give Capy the code you already have and tell it what you want changed. It reads the project until it understands how the thing actually works, plans the change in plain English, makes it, tests it and puts it live. **You approve what happens. Nothing ships that you didn't agree to.** ### It starts with your code Not a rebuild, not a migration, not a fresh start. The product you already have, however it was built and whoever built it. ### You describe the outcome "Customers in Germany can't check out." "Add a monthly plan." That is a complete request. You never have to describe how to do it. ### You approve, you don't supervise Read the plan, read the change, say yes. You are not steering it between those two moments, and it does not come back every ten minutes to ask what you meant. ## How it goes Six steps, and you only do the first and the fourth No tickets to write, no specification, no standup. You say what you need and you say yes. ### Tell Capy what you need In your own words. A sentence is enough. ### Capy understands your code It reads the project first — what is in it, how it fits together, what would break. ### Capy plans the change Written in plain English, so you can tell whether it understood you. ### You approve it Or send it back. Nothing is built from a plan you have not read. ### Capy builds and tests it On a copy of your code, never on the live version, so a bad idea costs nothing. ### Capy deploys it To your own servers, watching to see it worked — and putting it back if it did not. ## Sound familiar? However you got here, it is the same problem We are early, and working with our first founders. If this is you, [tell us what is stuck](https://capybari.com/contact/) — a person reads it. ### The developer left They knew how all of it worked. Nobody wrote any of it down. [What that looks like](https://capybari.com/use-cases/abandoned-codebase/). ### The agency is gone You own the code. You have no idea what is in it. [What that looks like](https://capybari.com/use-cases/abandoned-codebase/). ### The AI built it It works. Nobody wants to be the one who touches it. [What that looks like](https://capybari.com/use-cases/ai-generated-code/). ### A small change takes a week The code is old, the work is fiddly, and you have a business to run. [What that looks like](https://capybari.com/use-cases/agencies/). ### You are done babysitting the AI You could do it with one. You are tired of watching every step to get there. ### The backlog keeps growing Real features, real fixes, and nobody free to do them. ## How it works You bring the product. Capy keeps it moving. Everything between what you ask for and what your customers see — planning, building, checking, shipping, and watching it afterwards. Two moments need you. **Everything else is handled** — including the night it breaks. ### Your product, working ## Existing code welcome It reads your code before it changes anything Most software work does not start with a blank screen. Increasingly, it starts with an app that Claude or ChatGPT already built — fast, working, and now needing the process that got skipped: tests, review, a real deploy, someone who owns what happens when it breaks. It can just as easily be a codebase nobody fully understands, dependencies years behind, or decisions no one wrote down. Attach the repository and Capy learns the project before it changes anything in it. Take over the app you built with AI · take over a legacy application · add features to an existing product · modernise an old codebase · fix bugs in a system you inherited · upgrade dependencies · extend an API · continue work an engineering team started. ### Import Attach an existing GitHub repository to a project. Capy works on your repository, on branches, with the access you granted and nothing more. ### Understand Before the first change, Capy reads the architecture, the conventions the project already follows, its dependencies and how it is put together. What it learns persists — you are not re-explaining your own codebase every session. ### Plan A request becomes engineering tasks with an order and an owner: what has to change, where, and in what order. ### Change Each task runs on its own branch in its own isolated worktree, so parallel work cannot collide and nothing touches your default branch until it has passed the gates you set. ### Verify Tests, code review and a security pass happen before the merge, not after somebody notices in production. ### Ship Deploy to your own servers with a health check, and an automatic rollback if it fails. Then Capy keeps watching. ## Work on it together Do not wait for the engineer to come back When you would rather steer than delegate, open a live session. You describe what you want, Capy builds it in its own workspace, and a preview updates as it goes. Refine it as many times as you like. When it is right, say so — and it becomes a request, with most of the work already done. You interact with the outcome. Capy handles the implementation. ### You Say what you want changed "Make the onboarding flow simpler." Plain sentences, not tickets. Address a specialist directly when you want one — @PM, @Frontend. ### Capy Builds while you watch Work happens on a branch of your project in a workspace that persists between messages, so the second thing you ask for can build on the first. ### You again See it, then decide A live preview of the running application, not a description of one. Keep refining until it is right, then promote it to a request or send it to be deployed. ## Why you can hand it over Nothing ships that you did not agree to Handing your product to someone means knowing what they do when you are not watching. This is the answer to that, and it is the part that should decide whether you trust this at all. ### It thinks before it changes Planning and architecture come first A request becomes a plan before it becomes a commit. You see the plan, and in Manual mode nothing proceeds until you say so. ### It does not let agents collide Every task gets its own branch Isolated git worktrees, one per task. Parallel work cannot overwrite itself, and your default branch is untouched until the gates pass and the merge succeeds. ### It has people whose job is to say no Architecture, security and review are gates The architect, the security engineer and the code reviewer can stop work. Any role can be marked as needing human review, which holds everything downstream until you approve. ### It knows when to ask you Technical calls it makes; business calls it escalates Which library, which pattern, how to structure a migration — Capy decides. What the product should do, what it should cost, what risk is acceptable — you decide. ### It verifies before shipping Tested and reviewed before the merge QA, code review and a security pass run before anything reaches your default branch. ### It watches after shipping Health checks, rollback, investigations A failed health check rolls the deploy back on its own and opens an investigation with an agent assigned. Read-only by default: it diagnoses and proposes, and cannot change your server unless you grant that explicitly. ## A different category This is not another coding copilot Both are useful. The difference is who carries the work: an assistant makes you faster at doing it yourself, and still needs you in the chair. This is for when you would rather hand the whole thing over. No claim here about being the only one, or the first. Judge it on the combination — takeover, persistent project understanding, a specialist organisation, governance, live sessions, Brief, your own keys, and ownership of the deploy. New projects are easiest | Existing, legacy and AI-generated codebases are first-class Helps you write code | Owns the engineering workflow Needs you at every step | Asks only when it genuinely needs a decision You break down the work | Capy plans the work You manage the context | Capy learns the project and keeps what it learns You check the result | QA, code review and security check it You manage deployment | Capy deploys and watches You discover production failures | Capy rolls back and investigates them Stops when you stop typing | Keeps going while you do something else The model is the product | Models are interchangeable intelligence A coding assistant Capy ## Brief Fifteen minutes a day, and you are current Capy keeps working while you are away. When you come back, Brief walks you through each project in turn: what moved, what is blocked, what it recommends, and anything you mentioned that should become work. A project counts as briefed when you say you are done with it — not when the summary loaded — so a brief you abandon halfway does not silence tomorrow's. It keeps working whether or not you are watching. That is rather the point. ### The fifteen minutes #### 09:00 · You open Capy Everything since your last brief is waiting. Nothing needed watching overnight. #### 09:01 · Read the brief Checkout authentication shipped. Twenty-four tests added. The production deploy verified itself. #### 09:05 · Answer the one business question Payment retry behaviour was ambiguous. Capy recommends keeping the current policy and adding a 30-second backoff. You agree, or you say why not. #### 09:08 · Add what you thought of since Turkish. Team invitations. A change to onboarding. Say them; they become requests. #### 09:10 · Approve the plan The work Capy proposes for today, in the order it intends to do it. #### 09:12 · Ship it What is finished and reviewed goes out. ### The rest of the day #### Back to your actual job Capy works the other twenty-three hours and forty-five minutes, and escalates only what genuinely needs your judgement. ## Built in The things you would otherwise build yourself ### Autonomy you dial up Start at Manual and approve everything. Move to Supervised when the plans stop surprising you. Reach Autonomous when you trust the gates. Most teams take about three weeks. ### Investigations When production misbehaves, an agent is dispatched with read-only access. It reads logs and diagnostics, writes up the cause, and opens the request that fixes it. ### Your repositories GitHub, GitLab, Bitbucket, or any git remote over SSH. No git host at all? Upload a folder or a zip and Capybari makes it a repository. Either way it works on branches inside your repo — not on a copy in ours. ### Design previews Front-end work generates a shareable preview link so stakeholders can look before anything merges. ### Editable role contracts Every role's behaviour is a Markdown document. Tighten it, loosen it, or write your own. ### Live run streaming Watch a task work in real time — the commands it runs and the output it gets back. ### Talk to the manager Chat with the Project Manager about a project. It can turn the conversation into a request. ### Rollback that has run Not a checkbox in a settings page. A command you supply, executed the moment a health check fails. ## Built and run with Capy These are our own products, not customers' logos — we are early, and working with our first founders. When somebody else is willing to put their name here, it will be their name and their words. ## Pricing $50 per project, per month One plan, priced per project: **$50 a month for the first, $40 for each after.** Annual billing is ten months for twelve. No seats — viewers and collaborators are free, however many there are. **Reading is free. Changing is paid.** Capy reads your codebase and writes back what it found at our expense, before you pay anything; a licence starts when you want the first change made. The AI work runs on your own Claude or Codex subscription at no mark-up, so a busy month never arrives as a bigger invoice. [The full breakdown](https://capybari.com/pricing/), including what one licence covers. ## Objections The questions you are actually asking Still circling something? [Ask us directly](https://capybari.com/contact/) — a person replies. ### Does Capybari need access to my production servers? Only if you want it to deploy. A deployment target is an SSH host you define, with a deploy command, a health check and a rollback command that you write. Plenty of teams run Capybari for planning and building only and never connect a server at all. ### What stops an agent breaking my main branch? Every task runs on its own branch inside its own git worktree. Nothing touches your default branch until the review gates you configured have passed and the merge succeeds. Any role can be marked as requiring human review. When it is, dependent work stops until you approve — at every autonomy level, with no exceptions. ### What happens when a deployment breaks production? Your health check fails, your rollback command runs, and an investigation opens automatically. An agent with **read-only** access reads the logs and diagnostics, writes up the cause, and opens a follow-up request containing the fix. Write access to a production host is a separate, explicit grant. It is never the default. ### Do I have to let it run on its own? No, and we would rather you didn't at first. Projects start at **Manual**, where nothing runs until you press the button. **Supervised** starts planning on its own and dispatches work you have approved. **Autonomous** lets healthy work ship without you. Review gates and genuine escalations reach a human at every level. ### Is my code used to train models? No. Your repositories are cloned to run your work and nothing more. We do not train on your code, your prompts or your reports. The [security page](https://capybari.com/security/) sets out where your data lives and who can reach it. ### What if the plan it writes is wrong? Reject it, edit it, or say what it missed and have it planned again. Nothing is dispatched from a plan you have not approved unless you have deliberately turned that approval off. ### Can it work on an existing, messy codebase? That is the case we built for. Agents read your conventions before they plan, and the role contracts instruct every specialist to make the smallest safe change and to reuse existing patterns rather than introduce new ones. ### Are you ready for my enterprise? Almost certainly not, and we say so on the [pricing page](https://capybari.com/pricing/) with the specific list of what we are missing. If you need SSO at identity-provider grade, a completed SOC 2 audit or a contractual uptime SLA today, we are not your platform yet. ## Give Capy one problem and see what comes back Not the whole backlog. One thing that has been stuck — the fix you have been putting off, the feature nobody is free to build. Point Capy at the code, describe the outcome, and read the plan it writes back. Nothing runs until you say so. Free · no card · Capy reads your repositories and writes you a plain-English description of your own software --- # About URL: https://capybari.com/about/ Capybari gives a small team the engineering organisation it cannot staff: planning, review, security, deployment and investigation, running on your own infrastructure. ## 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. Founded 2025 Your repositories, your servers We publish what we cannot do yet ## 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](https://capybari.com/pricing/), 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. ## 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](https://capybari.com/roadmap/). ### specialist roles Coordinator, Governance and Worker roles, each with an editable Markdown contract. ### autonomy levels Manual, Supervised, Autonomous. You move up when the plans stop surprising you. ### branch per task Every task runs in its own git worktree, so parallel work never collides. ### sections in every task report Summary, Files Modified, Risks, Assumptions, Recommendations, Blockers. ## 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 Every role in the product is governed by a Markdown contract you can read and edit. We work the same way: a decision that is not written down has not been made. ### Review is not optional here either Nothing reaches our default branch without a review gate, including the marketing site you are reading. ### Remote, written, asynchronous We hire where the person already lives. Meetings are the expensive option and are treated that way. We work to New York hours, and hire where the overlap is workable rather than where the office would have been. ### Publish the gaps The [roadmap](https://capybari.com/roadmap/) says what is shipped, what is next, and what we are only considering. Nothing moves into "shipped" until you can use it. ### No dark patterns, written down as a rule Credits are bought before they are spent, never billed in arrears. When a balance runs out the work stops and waits — it does not carry on and arrive as an invoice nobody agreed to. ### One primary action Every page on this site has exactly one thing it wants you to do. If we ever put seven buttons in front of you, something has gone wrong internally. ## 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. ### Founded #### Capybari starts as an internal tool Built to solve our own problem: too much roadmap, not enough people to review it. Dackapps LLC was founded in October 2023 by Justin Green, who still writes the contracts the agents work to. #### The role contracts are written Fourteen specialist roles, each defined by a Markdown document setting out what it owns and where it must stop. ### First agent organisation #### 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 and investigations #### 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. ### Free plan opens #### One project, real gates, no card The free plan takes one repository — a new idea or a codebase you already run — and gives it the whole pipeline, at the setting 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. Free · no card · Capy reads your repositories and writes you a plain-English description of your own software --- # Accessibility statement URL: https://capybari.com/accessibility/ Our WCAG 2.2 AA target, what we have implemented on this site, the limitations we know about, and how to report a problem. ## Accessibility statement Capybari is committed to making capybari.com usable by everyone, including people who navigate with a keyboard, use a screen reader, need larger text, prefer reduced motion, or use high-contrast settings. This statement covers **capybari.com**, the public website. It does not yet cover the signed-in application at app.capybari.com — see *Known limitations*. ## Our target We are working to **WCAG 2.2 Level AA**. We have not commissioned an independent audit, so we describe this as a target we build against and test for, rather than a certification we hold. When that audit happens we will publish the findings here, including the ones we fail. ## What we have implemented Every item below is implemented on this site today and can be verified. ### Structure and semantics - Semantic HTML throughout: one `main` landmark, labelled `nav` regions for the primary navigation and footer, real headings in order, real lists, and real `table` markup with `scope` on header cells. - Accordions and the mobile menu are built from native `details` and `summary`, so they work with assistive technology and with JavaScript disabled. - A skip link is the first focusable element on every page and becomes visible when it receives focus. ### Keyboard - Every interactive element is reachable and operable by keyboard. - The desktop navigation opens on click as well as hover, so it is not a pointer-only affordance. - `Escape` closes any open menu and returns focus to the control that opened it. - `aria-expanded` is kept accurate on every disclosure control. - Focus is never trapped, and focus order follows visual order. ### Visible focus - A single focus treatment is used site-wide: a 2px outline in the brand accent with a 3px offset. - It has been checked against every background colour the site uses, in both themes. - Focus styling is never removed — only replaced. ### Colour and contrast - Body text meets or exceeds 4.5:1 in both light and dark themes; large text and interface components meet or exceed 3:1. - The one low-contrast token (`--fg-subtle`, ~3.1:1) is restricted by rule to decoration and input placeholders, never to body text or labels. - No information is conveyed by colour alone. Status is always carried by an icon and a word as well as a colour. ### Motion - Every animation on the site is disabled under `prefers-reduced-motion: reduce`, including scroll reveals, the hero entrance, and the progress indicator in the product mockup. - Nothing autoplays with sound. Nothing flashes. No animation moves more than 12px. - With all motion switched off, no content is hidden and no meaning is lost — the reveal effects are additive only, and content is visible by default when JavaScript is unavailable. ### Text and zoom - Type is set in fluid units and reflows to a 320px viewport with no horizontal page scrolling. - The layout survives 200% browser zoom and 400% text-only zoom. - Wide content — comparison tables, code samples — scrolls inside its own container rather than forcing the page sideways. - No text is set in an image. ### Forms - Every field has a real, programmatically associated `label`. Placeholders are examples, never substitutes for labels. - Errors are announced through a live region, described in words rather than colour, and identified per field with `aria-invalid`. - Required fields are marked in the label; optional fields are marked explicitly rather than left ambiguous. - Nothing has a time limit. ### Images and product visuals - The product mockups are built from live HTML rather than screenshots. Each carries one considered description of what it shows on the wrapper, and its decorative internals are hidden from the accessibility tree — so a screen reader gets a single coherent sentence instead of forty disconnected fragments. - Decorative graphics are hidden with `aria-hidden`. - Icons are hidden from assistive technology unless an icon is the only content of a control, in which case the control carries a label. ### Independence from third parties The site loads no third-party scripts, fonts, or trackers. Nothing on the page can be broken by a vendor changing their code, and no consent banner interrupts navigation. ## Known limitations We would rather list these than let you discover them. 1. **The signed-in application has not been fully audited.** This statement covers the marketing site. Accessibility work on app.capybari.com is ongoing, and we are not yet in a position to claim AA for it. 2. **No independent audit has been carried out.** All testing to date has been internal — keyboard traversal, screen reader spot checks, automated checking, and contrast verification against the token set. 3. **The uptime bars on the status page are decorative.** Each row's uptime figure is given as text, and the bars carry a summary label, but the per-day detail they show visually is not exposed individually. 4. **Some third-party content we link to is outside our control**, including community platforms and code hosting. 5. **We have not tested with every combination** of browser and assistive technology. Testing has concentrated on current versions of Chrome, Firefox and Safari with VoiceOver and NVDA. ## Reporting a problem If any part of this site is difficult or impossible for you to use, please tell us. You do not need to know why it is failing or what the standard says — a description of what you were trying to do is enough. - **Email:** accessibility@capybari.com - **Contact form:** [capybari.com/contact](https://capybari.com/contact/?topic=Something+else) We commit to: - acknowledging your report within **two working days**; - telling you what we found and what we intend to do within **ten working days**; - giving you the information another way in the meantime, if that is what you need. We will not ask you to prove the problem or to test a fix unless you offer. ## If we do not resolve it If you are not satisfied with our response, you can escalate to the **Equality Advisory and Support Service** — the body that advises on rights under the Equality Act 2010, including the duty to make reasonable adjustments to a digital service. They are reachable on 0808 800 0082 or through [equalityadvisoryservice.com](https://www.equalityadvisoryservice.com). We are a United States company, so the routes that apply to you depend on where you are. In the **United States**, rights of access to digital services arise under the Americans with Disabilities Act and, for federal procurement, Section 508 of the Rehabilitation Act. In the **United Kingdom** the EASS advises on the Equality Act. Elsewhere, the equivalent body where you live can advise you, and nothing here limits a right you have under your own law. We name these rather than listing every regulator, because getting one of them wrong would be worse than naming fewer. ## Keeping this honest This statement is reviewed whenever the design system changes materially, and at least twice a year. If we ship something that regresses accessibility, the fix is treated as a defect rather than an enhancement. Last updated 5 September 2026 ## Summary The measures, in short Semantic HTML with landmarks, real headings and real tables Skip link as the first focusable element on every page One visible focus treatment, checked on every background Full keyboard operation; `Escape` closes menus and restores focus `aria-expanded` accurate on every disclosure control Body text at 4.5:1 or better in both light and dark themes No meaning carried by colour alone All motion disabled under `prefers-reduced-motion` Reflows to 320px with no horizontal page scroll Survives 200% zoom and 400% text-only zoom Real labels on every form field; errors announced in a live region Product visuals built from live HTML with text alternatives No third-party scripts, fonts or trackers No time limits, no flashing, no autoplaying media ### Found something that does not work? Email **accessibility@capybari.com** or use the [contact form](https://capybari.com/contact/?topic=Something+else). We acknowledge within two working days and tell you what we are doing within ten. You do not need to diagnose it for us. --- # The agent team URL: https://capybari.com/ai/ Capy is one agent that puts on the right hat for the job: fourteen of them, each an editable contract, with one execution cycle and a structured report every time. ## How Capy works One agent. Fourteen hats. There is one agent here, called Capy, and it is not a team in a trench coat. What changes between planning your request, writing the migration, designing the screen and shipping it is **which hat Capy is wearing** — which skills it brings, and which written contract it works to. Fourteen hats, every one editable, so the expertise applied to a job is something you can actually change. Contracts in plain Markdown Substitutions recorded, never silent Escalation to a human at every level ### hats Capy can wear The right skills for the job, named so you can see which were applied. ### capability domains Product, software, design, operations, marketing, research, business, communication. ### phases per run The same execution cycle whichever hat is on, every task. ### headings in every report Same shape each time, which is what makes reports skimmable. ## The hats The fourteen hats Not a roster of people, and not agents queuing to be assigned. Each of these is a set of skills and a written contract Capy works to when the job calls for it. Two of them are about how much you hand over — the assistant that talks things through, and full execution for when you would rather it just went and did it. The rest are the expertise it brings to the work itself. Any hat can be flagged as requiring your review before what it produced goes anywhere. ### Capy Executive Assistant ### Capy Full Execution ### Product Owner ### Project Manager ### Architect ### Developer ### QA Engineer ### Security Engineer ### DevOps Engineer ### UI/UX Designer ### iOS Developer ### Android Developer ### Marketing Manager ### Product Marketing Manager ## One run, six phases How Capy works a task The same execution cycle every time, whichever hat is on. You can watch it happen: run streaming shows the commands and the output as they arrive. ### Observe Read the task, the request behind it, the contract for the role, and the state of the repository it has been given. ### Analyse Work out what the change actually requires, which conventions already exist, and what could go wrong if it is done carelessly. ### Plan Decide the smallest safe change and the order to make it in — before touching a file, not while explaining a mess afterwards. ### Execute Do the work on its own branch in its own worktree. Where the right answer is genuinely unclear, stop and ask a human instead of guessing. ### Validate Check the work against what the request asked for. Run what there is to run. Confirm nothing outside the task's remit has moved. ### Report Write the structured report: summary, files modified, risks, assumptions, recommendations and blockers. Then hand the branch to the gates. ## The handover Every task ends the same way Six headings, in the same order, on every run whichever hat was on. Consistency is the entire point — a report you have to decode is a report you stop reading. ### Summary what changed and why, in language you can forward to someone who was not watching. ### Files Modified the surface area of the change, so you know where to look before you open the diff. ### Risks what this could break. Written by the agent that did the work, while it still remembers. ### Assumptions the calls it made that you might have made differently. This is usually the most valuable heading. ### Recommendations the follow-up work it noticed and deliberately did not do. ### Blockers why it could not finish, if it could not finish. Silence is never the answer. ### completion-report.md ## The mechanics Why the hat matters at all If it is one agent either way, why name the hat? Because naming it is what focuses the work: a written contract, a capability the plan can ask for by name, one report shape whatever was applied, and permission to stop. ### Role contracts Every role is a document you can read A hat is not a prompt buried in our source. It is a Markdown contract describing what that expertise covers, how it should be applied, and what it must never do. Open it. Argue with it. Change it, and the next run works to your version. #### Editable write your conventions into the QA Engineer's contract and they apply on every task, not on the ones you remember to mention. #### Scoped a contract says where that expertise stops. That boundary is why a copy change does not quietly turn into an architecture rewrite. #### Legible if you want to know why an agent did something, the answer is in a document rather than in a support ticket. ### Capability substitution When the hat you asked for isn't the one that fits A plan asks for a capability, not for a person. Where the work needs expertise the named hat does not cover, Capy applies the one that does — and writes down that it did. #### Capability, not job title the plan asks for a capability, and the hat holding it takes the task. There is no roster to check and nobody to wait for. #### Recorded, never silent you can see that the Developer hat covered the database work, which matters when you read the diff later. #### It stops rather than stretches if no hat genuinely covers the capability the work needs, the run halts and asks you instead of improvising. ### Structured reports The handover is the product Specialists do not talk to each other in free text. Work moves between them as a branch plus a report with the same six headings every time, which is what lets a reviewer start reading rather than start interpreting. #### The same shape every time one format across fourteen roles means you learn to read it once. #### Assumptions in writing the judgement calls are stated, so disagreeing with one is a conversation rather than an archaeology exercise. #### Blockers are first-class a task that cannot finish says why. Nothing is more expensive than plausible silence. ### Escalation It is allowed to stop and ask you The most useful thing an agent can do with genuine ambiguity is refuse to resolve it alone. Capy can pause mid-run, put a question to you, and wait — the task holds until you answer. #### A question, not a guess an agent that invents a business rule at 2am has produced work that looks finished and is not. #### Review gates are the other stop any hat flagged as requiring review halts dependent work until a human approves, however far the rest is allowed to run. #### Escalation reaches you questions and gates arrive at a person even on Autonomous. Autonomy changes the routine, not the exceptions. ## Your side of it How you tune it ### Staff each project separately Each project has its own set of hats and its own contracts. The marketing site and the billing service do not have to be worked the same way. ### Rewrite a contract Tighten a standard, loosen one, or add the rule your codebase has always had and never written down. ### Decide who stops the line Flag any hat as requiring human review. Work done under it then holds dependent tasks until a person approves. ### Choose the model and effort Override both per project, or for a single request that deserves more thought than the rest of the queue. ### Set the autonomy level Manual, Supervised or Autonomous. How much of the routine runs without you; never how the gates behave. ### Watch a run live Streaming shows the commands Capy runs and the output it gets back, while it is still running them. ## Vocabulary The words we use, and what they mean We use the same terms in the product, the docs and here. If one of them means something specific, it is defined below rather than left to context. ### Hat A named set of skills and the written contract that governs them. Capy puts one on for a piece of work; it does not become a different agent, and there is no handover when the work moves on to another kind of expertise. ### Assists you Two of the fourteen are about how Capy engages rather than what it knows. **Capy Executive Assistant** talks a request through with you. **Capy Full Execution** is the other end of the same dial: hand over the whole thing and read the report, with the review gates you set still stopping for you. ### Worker agent The expertise applied to producing the thing: **Architect**, **Developer**, **QA Engineer**, **Security Engineer**, **DevOps Engineer**, **UI/UX Designer**, **iOS** and **Android Developer**, plus **Product Owner** and **Project Manager** for deciding what is worth doing and in what order, and **Marketing Manager** and **Product Marketing Manager** for the work that is not code at all. ### Capability vs role A **role** is a named seat on the team with a contract. A **capability** is something a role can do. Plans ask for capabilities, which is why an absent role does not stop the work. ### Temporary responsibility What a role takes when capability substitution hands it work that belongs to a role your team does not have. It is temporary, it is scoped to the task, and it is recorded on the task. ### Review gate The stop created by flagging a role as `requires_review`. Dependent work waits for a human approval, at every autonomy level, with no override for urgency. ### Escalation Capy pausing a run to ask you a question, rather than resolving an ambiguity on its own. The task waits until you answer. Escalations reach a person even on Autonomous. ### Run One task executed end to end, through all six phases of the execution cycle. It is also the unit we meter, because it is the unit that produces something. ## Questions About the agent itself Want to read a contract before you sign up? [Ask us for one](https://capybari.com/contact/). ### Why fourteen hats instead of just one very capable agent? It *is* one very capable agent. The hats are how it is pointed at the right skills for the job in front of it — shipping an iOS build and writing a launch announcement need different expertise, and saying which one is being applied keeps both the work and the record legible. Each hat is also a narrow contract, and a narrow contract is easier to read, edit and trust than one enormous set of instructions covering everything at once. Less irrelevant context also costs less to run, but that is a consequence rather than the reason. ### So who reviews the work, if it is all one agent? **You do, and we are not going to dress that up.** Validation is a real phase of every run with its own contract, and work done under the QA or Security hat genuinely checks the change against what was asked rather than against itself — but it is the same agent, so it is self-checking, not independent review. The independent review is the gate you set. Flag any hat as requiring human review and dependent work stops until a person approves it, however far you have let the rest run. Every task also arrives on its own branch, so what you are approving is a diff you can read and throw away. ### What does an agent see of my codebase? The repositories connected to the project it is working on, checked out into the worktree for its own task. Not another task's working directory, and not another project's repositories. ### Is my code used to train models? No. Your repositories are cloned to run your work and nothing more. We do not train on your code, your prompts or your reports. [The security page](https://capybari.com/security/) sets out where your data lives and who can reach it. ### What happens if an agent gets it wrong? The work is on its own branch, in its own worktree, and has not touched your base branch. Reject it and the branch goes away. If it reached production, the health check catches it, your rollback command runs, and an [investigation](https://capybari.com/platform/#investigations) opens. ### Can I add a role of my own? Yes, on any plan. A custom hat is a contract in the same Markdown format as the fourteen that ship with the product, and Capy works to it exactly the same way. ### How do I know which hat did what? Every task carries its owner, its branch and its completion report, and any capability substitution is recorded against it. The board shows the attribution without you having to reconstruct it from commits. ## Meet the team on your own codebase Connect a repository and file one request. The Project Manager plans it, you read the plan, and nothing else moves until you say so. No card required · Contracts are editable from day one · Manual autonomy by default --- # API reference URL: https://capybari.com/api/ A preview of the Capybari REST API: projects, requests, tasks, runs, deployments and investigations. Public API v1 is planned for Q4 2026. ## API reference The API, before it is an API Capybari has a REST interface, because the application is built on one. It is **not** a supported public API yet. This page shows you the shape of what is coming so you can plan — not so you can ship against it this week. ### Not generally available Public API v1 — with stable versioning, published rate limits, scoped tokens and outbound webhooks — is planned for **Q4 2026**. Until then these endpoints exist to serve the web application. They are undocumented in the product, unversioned, and will change without notice. If you build on them now, assume you are maintaining that integration yourself. ### Building something anyway? Tell us what you are trying to do. Several endpoints on the v1 list are there because somebody asked. [Get in touch](https://capybari.com/contact/?topic=Partnerships). ## Authentication Every request carries a bearer token Tokens are issued per user and inherit that user's access. Scoped machine tokens with per-project permissions are part of the v1 work. ### Bearer token sent in the `Authorization` header; never in a query string. ### Ownership enforced server-side a token cannot read a project it does not own, regardless of the id you pass. ### JSON in, JSON out `application/json` throughout. Errors carry a machine-readable code and a human-readable message. ### HTTPS only plain HTTP requests are refused rather than redirected. ### Authentication ### Error shape ## Requests Filing work and reading the plan A request is the unit you create. Everything else — the plan, the tasks, the runs, the deployment — descends from it. ### POST /api/requests ### GET /api/requests/{id} ## Runs Watching a task work Runs stream over Server-Sent Events. This is how the board shows you commands and output as they happen rather than after the fact. ### GET /api/runs/{id}/events (SSE) ### GET /api/tasks/{id} ## Deployment and investigations Shipping it, and what happens when it breaks ### POST /api/deployment-targets/{id}/runs ### GET /api/investigations/{id} ## Surface Endpoints What exists today, and what v1 will add. Nothing here is stable until v1. "Internal" means it powers the application and may change without notice. Do not build against it. `/api/projects` | GET, POST | List and create projects | Internal `/api/projects/{id}/repos` | GET, POST | Connected repositories | Internal `/api/requests` | GET, POST | File and list requests | Internal `/api/requests/{id}` | GET, PATCH | Read a request and its plan | Internal `/api/requests/{id}/approve` | POST | Approve a plan and dispatch work | Internal `/api/tasks/{id}` | GET | Task detail and completion report | Internal `/api/tasks/{id}/respond` | POST | Answer a question from an agent | Internal `/api/runs/{id}/events` | GET (SSE) | Live run stream | Internal `/api/deployment-targets` | GET, POST | Configure targets | Internal `/api/deployment-targets/{id}/runs` | POST | Trigger a deployment | Internal `/api/investigations` | GET | List and read investigations | Internal `/api/agent-profiles` | GET, POST | Project team members | Internal `/api/role-contracts` | GET, PUT | Read and edit role contracts | Internal `/api/webhooks` | — | Outbound event delivery | **Planned · Q4 2026** `/api/tokens` | — | Scoped machine tokens | **Planned · Q4 2026** Endpoint Method Purpose Status ## Planned Webhook events The event set we intend to ship with v1. Names are not final. `request.planned` | The manager finishes planning | Notifying an approver `request.approved` | A plan is approved | Kicking off external tracking `task.review_required` | A review gate stops work | Paging the right human `task.input_required` | An agent asks a question | Getting an answer quickly `task.completed` | A task finishes and reports | Pulling the structured report `deployment.succeeded` | A health check passes | Release announcements `deployment.rolled_back` | A health check fails and rollback runs | Incident channels `investigation.opened` | An investigation starts | On-call routing `investigation.resolved` | A cause is written up | Postmortem tooling Event Fires when Most useful for ## Objects The nouns you will be working with ### Project Owns repositories, a team of agent profiles, deployment targets and an autonomy level. The unit of isolation between clients or products. ### Request What you file. Typed, prioritised, orderable on the board. Carries a plan summary and the planned task list once the manager has read it. ### Task One unit of work for one specialist, on its own branch in its own worktree. Declares `depends_on`, may hold a review gate, and ends in a structured completion report. ### Run One execution of one task. Streams events. A task can have several runs if it is retried or continued after answering a question. ### Agent profile A role on a project team: system prompt, rules, model and effort defaults, permission mode, and whether it requires human review. ### Deployment target An SSH host with a deploy path, a deploy command, a health check, a diagnostics command and a rollback command. ### Deployment run One attempt to ship. Records its phase, merge summary, deploy output, health-check output and — if it came to it — rollback output. ### Investigation Opened when something fails in production. Carries an access level (`read_only` by default), a summary, a resolution, and optionally the request it opened to fix things. ## Questions About the API ### Can I use these endpoints now? You can call them, and they will work. They are also unversioned and undocumented in the product, and we will change them without telling you. That is an honest description of an internal interface, not a warning we expect you to ignore. ### When is v1 actually coming? Q4 2026 is the intention on the [roadmap](https://capybari.com/roadmap/). We publish quarters, not dates, and we do not commit contractually to either. ### Will v1 break what is here today? Almost certainly, in places. v1 adds scoped tokens, stable versioning under a `/v1/` prefix, published rate limits and webhooks. The object shapes above are the ones most likely to survive largely intact. ### Is there an SDK? No, and there will not be one before v1. A client library wrapping an unstable interface is worse than no client library. ### How do I get notified about changes? Everything that ships lands on the [changelog](https://capybari.com/changelog/), and the monthly community update covers anything that would break an integration. ## Tell us what you would build The v1 surface is still being decided. If you have a concrete integration in mind, now is the moment it can still change the shape of it. --- # Ask Capybari URL: https://capybari.com/ask/ Tell Capybari what you want to know about your software and it answers, then points you at the part of the site that actually helps. --- # Blog URL: https://capybari.com/blog/ Essays from the team running a managed AI engineering organisation: what review gates catch, why every task gets its own git worktree, and what a red deploy teaches you. ## Blog Notes from the board Writing about the parts of software delivery that happen after the code exists — review, isolation, deployment, and the quiet hour afterwards. Written by the people who build and operate Capybari. Engineering and operations essays No guest posts One digest a month ## Featured The one to start with ### What a review gate actually catches Broken code is the least interesting thing a review pass stops. The rejections worth studying are the ones where the change works, does what was asked, and quietly contradicts a decision the codebase already made. We sort the verdicts into three kinds and explain why only one of them is a bug. 29 July 2026 · 9 min read ## Recent Latest posts ### Why every task gets its own git worktree A branch on its own is not enough once four specialists are working at the same time. What a shared checkout does to parallel work, and why abandoning a task should mean deleting a directory rather than unpicking an afternoon. 22 July 2026 · 7 min read ### Moving through the three autonomy levels Manual to Supervised is a decision about plans. Supervised to Autonomous is a decision about gates. They are different questions, and treating them as one is why teams stall halfway. 16 July 2026 · 6 min read ### What an agent should do when it doesn't know Guessing is cheap to do and expensive to own. The rule lives in the role contracts: hit genuine ambiguity, stop the run, ask a question. The hard part is defining genuine. 9 July 2026 · 8 min read ### The economics of an agent run A run is what we meter because a run is what costs us money. Opening one up — plan, execute, review, report — explains why a small request sometimes costs more than a large one. 2 July 2026 · 10 min read ### Why we publish what we cannot do Our pricing page lists, by name, the things an enterprise needs that we do not have yet. Writing that list was uncomfortable. We would write it again. 25 June 2026 · 5 min read ## Engineering How the work is isolated, ordered and reassigned Posts about the machinery: worktrees, dependency graphs, parallel execution and what happens when a role is missing. ### What breaks when four agents work in parallel Isolation solves collisions in the working tree. It does not solve two tasks that both decide to rename the same function, so the interesting failures move up into the plan. 18 June 2026 · 9 min read ### Dependency graphs make better plans than checklists A numbered list records the order you imagined. A graph records what genuinely has to wait for what. The difference shows the moment one task blocks and three others could have carried on. 11 June 2026 · 6 min read ### Why capability substitution beats failing a task When the hat a plan named does not cover the work, it is reassigned to whoever can cover it — and the substitution is recorded. The record matters more than the reassignment does. 4 June 2026 · 7 min read ## Operations Deploying, checking, and the hour after it goes red Posts about deployment targets, health checks, rollback and the investigation that follows a bad night. ### Designing a rollback you can trust You write the rollback command, so it is only as good as the last time you ran it on purpose. Run it on a Tuesday afternoon, not during the deployment that needs it. 28 May 2026 · 8 min read ### The shape of an investigation write-up Timeline, cause, blast radius, what changed, what we still do not know. The last section is the one everyone skips, and it is the reason the next investigation is shorter. 21 May 2026 · 6 min read ### What a deployment target needs before you trust it A deploy path, a deploy command, a health check, a diagnostics command, a rollback command. Only the health check can tell you the deploy went wrong, so write one that fails when it should. 14 May 2026 · 7 min read ## Working with agents Reading what they write, and writing what they read Posts about the two documents you will spend the most time with: the request going in and the report coming back. ### Reading a completion report Summary, files modified, risks, assumptions, recommendations, blockers. Read the assumptions first — that section is where a task quietly tells you it filled in a gap. 7 May 2026 · 5 min read ### Writing a request that plans cleanly Describe the outcome and the constraint, not the implementation. The worst plans come back from requests that had already decided which file to change. 30 April 2026 · 6 min read ### Approving a plan you did not write You are not marking prose. Check the owners, check the order, then check what the plan has decided not to do. The third one is where the surprises live. 23 April 2026 · 7 min read ## Browse By category Five things we write about, and nothing else. ### Engineering Worktrees, branches, dependency graphs, parallel execution and the failures that only appear at four tasks at once. ### Operations Deployment targets, health checks, rollback commands and the investigation that opens when a check goes red. ### Autonomy Manual, Supervised, Autonomous: what each level actually changes, and how to tell when you are ready for the next one. ### Working with agents Writing requests, approving plans, reading structured reports, and answering the questions a run stops to ask. ### Company How we decide what to build, what we refuse to claim, and why the awkward parts go on the website rather than in a sales call. ### Changelog Not an essay category. If you want the dated list of what changed in the product, it lives on the changelog. ## The digest One email a month New posts, plus a short note on what shipped. No drip sequence, no sales follow-up, and one click to stop. We store your address to send the digest and nothing else. [How we handle data](https://capybari.com/privacy/). ### email Email address ## Reading about it is slower than watching it Connect a repository, file one request, and read the plan that comes back. Manual autonomy — nothing runs until you say so. Free · no card · Capy reads your repositories and writes you a plain-English description of your own software --- # Bring your code URL: https://capybari.com/bring-your-code/ Hand Capy the codebase you already have — however it was built, whoever built it — and tell it what you want changed. You approve the plan. ## For founders with a product already built Bring the code you already have. However it was built. Whoever built it. Whatever state it is in. Point Capy at the repository, tell it what you want changed, and read the plan it writes back before anything happens. No card required Nothing runs until you approve it Your repository, your servers ## What happens next Four steps, and two of them are yours ### Connect the repository Any git remote — GitHub, GitLab, your own server. Read access is enough to begin. ### Capy reads it It works out what the project is made of and how it fits together, and writes that down before touching anything. ### You ask for something A fix, a feature, a thing that has been annoying you for months. One sentence is enough. ### You approve the plan Written in plain English. Approve it and Capy builds, tests and ships it. Reject it and nothing has been spent but a few minutes. ## What it works with Especially the code nobody wants to open New projects are the easy case. This was built for the other one — software that already has customers, history and nobody who remembers writing it. ### Built with AI Claude, ChatGPT, Cursor, Lovable. It runs, and nobody is quite sure how. ### Legacy and undocumented Years old, no tests, no README, and the person who understood it is gone. ### Handed over by an agency You own it now. That is not the same as being able to change it. ### More than one repository A front end and an API and a worker. One request can span all of them. ### Half-finished Somebody started a migration and stopped. Capy reads what is actually there. ### Already in production Real customers on it. That is exactly why nothing merges without you. ## Before you hand anything over What Capy will not do to your code **It never works on your live code.** Every task gets its own branch and its own copy. **Nothing merges without your approval** unless you deliberately turn that off. **It reads before it writes.** The first thing it does with a new repository is understand it. **A bad plan costs nothing.** Reject it and there is nothing to unpick. **Deployment is opt-in.** Connect no server and Capy plans, builds and reviews only. **A failed deploy rolls back on its own**, to the last version that passed its health check. **Your code stays yours.** It lives in your repositories, on branches you own. **Export everything, any time** — requests, plans and reports, before or after you leave. ## Start here Give Capy one thing to fix Not the whole backlog. One thing that has been stuck. Create an account, connect a repository, and read the first plan it writes back. No card. You set your password in the app on the next screen — this page never asks for one. By creating an account you agree to our [terms](https://capybari.com/terms/) and [privacy policy](https://capybari.com/privacy/). ### email Work email ### company Company or project name ## Before you ask The three questions everybody has Something else on your mind? [Ask us](https://capybari.com/contact/) — a person replies. ### Do I need to understand the code to use this? No, and that is rather the point. You describe what you want in ordinary language — "customers in Germany can't check out" is a complete request — and Capy reads the code to work out what that means. The plan it writes back is in plain English, so you can tell whether it understood you without reading a diff. ### What if it breaks something that currently works? Every task runs on its own branch, on its own copy, never on your live code. Nothing merges until you approve it. If you connect a deployment target and a release fails its health check, the previous version is restored automatically and an investigation opens to work out why. ### Is my code used to train models? No. Your repositories are cloned to run the work you asked for and nothing else. We do not train on your code, your requests or your reports. Work sent to model providers goes under agreements that forbid training on it, and on any plan you can connect your own provider account and cut us out of that relationship entirely. The [security page](https://capybari.com/security/) sets out where your data sits. ## Your code is not too messy for this It has seen worse, and the first thing it does is read. Connect one repository and find out what it makes of yours. No card required · Nothing runs until you approve it · Export everything, any time --- # Careers URL: https://capybari.com/careers/ Work on the agent runtime, the deployment pipeline and the gates behind Capybari. Small remote team, written decisions, and a product that reviews its own work. ## Careers Build the part everyone else skips. Anyone can make a model write code. We are building the review gate, the isolated worktree, the health check and the rollback that make it safe to let it. That is the hard half, and it is the half we hire for. Remote-first Written decisions, few meetings You will use the product daily ## What it is actually like Six things that are true here and not everywhere No table tennis. Here is what genuinely differs, including the parts you may not want. ### You file requests into the product you build Work on Capybari reaches Capybari's own board. You will plan a request, approve a plan, review an agent's diff and read its completion report before lunch. Every bad edge in the product is an edge you personally hit. ### Written before spoken A decision that is not written down has not been made. Proposals are documents, not slide decks, and they get read before the call rather than presented during it. ### The gates apply to us Nothing reaches our default branch without review, and anything touching deployment, credentials or the agent sandbox gets a security pass. Being in a hurry is not an argument that has ever worked here. ### You will be near production incidents We ship a product whose job is deploying other people's software. When ours misbehaves, engineers look at it — not a separate operations team. If that is not the job you want, this is the wrong company and we would rather say so now. ### We publish our gaps in public The roadmap says what we have not built. The pricing page lists what Enterprise buyers cannot have yet. You will be asked to write those sentences about your own area, and to resist the urge to soften them. ### Small enough that scope is yours You will own an area rather than a ticket queue, and you will do some of your own design, testing and support triage. Nobody's job title decides whose answer is right. ## Open roles Where we need people right now Each role links to a short application form. Tell us what you have built; a person reads every one. ## The roles in one paragraph each What you would actually be doing **Founding Engineer — Agent Runtime.** Own the loop that turns a planned task into a finished branch: dispatch, the worktree lifecycle, dependency ordering, live run streaming, the mid-run question a specialist asks a human, and the structured report at the end. You will spend real time on failure modes, because that is where the product is judged. **Backend Engineer — Deployment & Operations.** Own deployment targets and everything downstream of merge — the SSH transport, deploy phases, health-check types, diagnostics, automatic rollback to the last healthy commit, and the investigation that opens when a deploy fails. If you have carried a pager and have opinions about what should have been logged, we want the opinions. **Product Designer.** Own the board, the plan view, the review gate and the investigation timeline. The brief is unusual: the interface must get *quieter* as the situation gets more serious. You will design dark and light as equals, work at 320px first, and be asked to delete more than you draw. **Developer Advocate.** Write the guides, record the walkthroughs, run office hours in Discord, and answer the hard questions in public. This is a writing job first. If you cannot explain an isolated git worktree to a non-technical founder in three sentences, this will be uncomfortable. **Customer Engineer.** Sit with new teams through their first request, first review gate, first deployment target and first rollback, then feed what you learn straight back into the product. Part support, part solutions engineering, part product research. The people who do this job well end up deciding the roadmap. **Security Engineer (part time or contract).** Review the agent sandbox, credential handling, the read-only default on investigations and the write-access escalation path. Run our disclosure process. Tell us, in writing, what we are still getting wrong. We are pre-audit and say so on the pricing page; you would be the person who changes that. ## Hiring process Four stages, about three weeks, no surprises We tell you the whole process at the start and we do not add stages to it afterwards. The shape below is what we run; the exact timings and the rate for the paid exercise are confirmed in writing when a role opens, because quoting them here for a vacancy that does not exist yet would be a number we might not keep. 1. **Application — you write, we read.** Send the form, or email [careers@capybari.com](mailto:careers@capybari.com). No cover letter theatre; two paragraphs about something you built and what went wrong with it beats a page of adjectives. **We reply within five working days, including when the answer is no.** 2. **Intro call — 30 minutes, with the person you would work with.** Not a recruiter screen. We describe the role honestly, including the parts that are tedious, and you ask whatever you like about the company. Salary band and equity are discussed here, not at the end. 3. **Paid exercise — about three hours, done in your own time within a week.** A real, scoped problem from our backlog. We pay for your time at a fair contract rate whether or not we make an offer. You may use Capybari, or any other agent tooling, and we would rather you did — how you review what a machine wrote is exactly what we are trying to observe. 4. **Two conversations — 60 minutes each, in the same week.** One on the exercise: what you decided, what you rejected, what you would do with another day. One on working together: how you handle disagreement, ambiguity and the Friday-evening deploy you should not do. **Then a decision within three working days**, with a written reason either way. References only after an offer, and only with your say-so. We do not run whiteboard algorithm rounds, we do not ask for unpaid take-home projects, and we will not ask you to build a feature we intend to ship. ## None of these fit? Write to us anyway ### Speculative applications are genuinely read Send one paragraph on what you would own, one link to something you built, and the month you would be free, to [careers@capybari.com](mailto:careers@capybari.com). Skip the CV until we ask. If the fit is obvious we will make a role; if it is not, we will say so within ten working days and keep your note on file for six months with your permission. ### What helps most Something we can read. A repository, a post-incident write-up, a design case study, a support thread you are proud of. We care far more about how you explain a decision than where you have worked. ### Accessibility and adjustments Tell us what you need at any stage and we will arrange it — extra time, a different format, written questions in advance. It never counts against an application, and it goes no further than the hiring manager. ## Use the product before you apply The free plan takes a few minutes and one repository. File a request, read the plan, and turn up to the intro call with an opinion about what we got wrong. No card required · A person replies to every application --- # Changelog URL: https://capybari.com/changelog/ Dated record of every capability we have shipped, from the first board to production investigations and automatic rollback. ## Changelog Everything we shipped, dated No "various improvements and bug fixes". If it changed what the platform can do, it is on this page with the month it landed. What is coming next lives on the [roadmap](https://capybari.com/roadmap/). ### July 2026 #### Production investigations A failed deployment now opens an investigation automatically. An agent is dispatched with read-only access by default, reads logs and diagnostics output, writes a summary and a resolution, and can open a follow-up request carrying the fix — linked back to the incident that caused it. #### Investigation access levels Investigations run read-only unless you explicitly raise them to write access. The level is recorded on the investigation, so there is always a record of what an agent was permitted to do. #### Design previews Front-end tasks generate a shareable preview link. Stakeholders can see the built interface in a browser before anything is approved or merged — no deployment required. ### June 2026 #### Automatic rollback When a health check fails after a deploy, your rollback command runs on its own and the target is restored to the last commit recorded as healthy. The rollback output is kept on the deployment run alongside everything else. #### Health checks and diagnostics Deployment targets now take a health check and a diagnostics command. A target with no health check cannot be marked healthy, which is what makes rollback trustworthy rather than optimistic. #### Deployment phases and merge summaries Deployment runs report their phase as they go — merge, deploy, health check, rollback — with a summary of every branch that went into the merge. ### May 2026 #### Three autonomy levels Projects run at Manual, Supervised or Autonomous. The level controls whether planning starts on its own, whether approved work dispatches itself, and whether healthy work deploys without you. Review gates and escalations still reach a human at every level. #### Task review gates Any role can be marked as requiring human review. When it is, dependent tasks stop until you approve — regardless of the project's autonomy level. #### Role contract editor The Markdown contract governing each of the fourteen roles is now editable in the application. Tighten a role's remit, loosen it, or write your own. ### April 2026 #### Deployment targets over SSH Connect a server with a host, port, username and key, then give it a deploy path and a deploy command. Keys are generated and stored encrypted; you install the public half. #### Deployment target types Targets can describe different shapes of deployment rather than assuming one, with a per-target repository path and default-target selection. #### Multiple repositories per project A project can connect several repositories, and a task is scoped to the one it needs. Each repository records when its connection was last verified. ### March 2026 #### Live run streaming Watch a task work as it happens — the commands it runs and the output it gets back, streamed to the board rather than collected at the end. #### Project chat with the Project Manager Talk to the manager agent about a project. It has the project's context, and it can turn the conversation into a filed request. #### Agents that ask A specialist that hits genuine ambiguity now stops and asks a question instead of guessing. The task waits in an awaiting-input state until you answer. ### February 2026 #### Agent profiles and project teams Assemble a per-project team from the fourteen roles. Each profile carries its own system prompt, rules, model and effort defaults, and its own icon. #### Capability substitution Work planned for a role that is not on the team is reassigned to whichever member can cover it, and the substitution is recorded on the task. A task never disappears for lack of a specialist. #### Structured completion reports Every task now ends in the same shape: summary, files modified, risks, assumptions, recommendations and blockers. Parsed, not just written — the manager reads the risk signal without reading the logs. ### January 2026 #### Requests, tasks and the board The first version of the thing: requests you file, tasks the manager plans, and a board that shows both. Typed, prioritised and orderable from the start. #### Isolated worktrees per task Every task runs on its own branch in its own git worktree. Parallel work cannot collide, and an abandoned task is a deleted branch. #### Task dependency graphs Tasks declare what they depend on. Work that is not ready simply waits, and the graph is visible on the board rather than buried in a plan. #### Multi-tenant ownership Projects, repositories, agent accounts and deployment targets are owned, and the boundaries are enforced at the query level rather than in the interface. ### Where the older history went Capybari ran as an internal tool before it was a product. Entries before January 2026 predate the platform being something anyone else could use, so we have left them out rather than dress them up as releases. ## See what is coming next The roadmap is public, dated by quarter, and honest about what is still missing — including the things that keep us out of enterprise accounts. --- # Community URL: https://capybari.com/community/ Ask a question in Discord, bring a problem to monthly office hours, request a feature, or read what shipped last month. Run by the people who build the product. ## Community Ask the people who build it. Most questions about agent teams do not have a documentation page yet, because nobody has written one. So we run the channels where those questions get answered — by us, and increasingly by each other. Free on every plan Engineers answer, not a script Office hours every month ## Where to find us Six places, each with a job Pick the one that matches what you need. Posting in the wrong place is fine — someone will move you, politely. ### Discord The busy room. Setup questions, role contract tuning, deployment target patterns, and the channel where people post a plan and ask whether it looks sane. ### GitHub discussions The slow, searchable room. Longer write-ups, reproducible problems, and answers you can link to six months later without them scrolling away. ### Monthly office hours One hour, live, with whoever is building the thing you want to talk about. Bring a run that went wrong. No slides, and no demo unless somebody asks. ### Feature requests Describe the workflow you are stuck in and we will tell you which roadmap bucket it landed in — including when the answer is no. ### The changelog Everything that shipped, with the date it landed and what it changes about how you work. Written for people who already use the product. ### Community showcase Role contracts, health check scripts and deployment target setups that other teams have shared. Copy them, break them, send back the improvement. ## Getting an answer How to get help fastest The difference between an answer in four minutes and an answer tomorrow is almost always what is in the first message. ### Search first, briefly Two minutes in the [docs](https://capybari.com/docs/) and the [help centre](https://capybari.com/help/). If the answer is there, you get it now instead of after lunch. ### Bring the run Paste the task report — summary, files modified, blockers — or the deploy and health check output. The report is designed to be pasted. ### Say what you expected "The reviewer rejected it and I thought it would pass" tells us where to look. "It's broken" starts a game of twenty questions. ### Escalate real breakage Anything touching your production systems goes to [support](https://capybari.com/contact/?topic=Support), not Discord. That route is tracked and has a response time. ## Guidelines How we behave in here Short, specific, and enforced. If a rule below reads like it was written after something happened, that is because it was. **Redact before you paste.** Reports and deploy logs pick up hostnames, tokens and customer data. Nobody in a public channel needs your production connection string. **Ask the whole question in one message.** "Anyone around?" costs everyone an hour. Ask, then wait — someone will be around. **Answer the question that was asked.** If you want to argue that they should be doing something else entirely, answer first, then say so. **Nobody's setup is stupid.** Half the people here inherited a codebase from someone who left. "Why would you do it that way" is never the useful sentence. **Say when you are guessing.** A confident wrong answer about a deployment target can cost somebody their evening. "I think, but check it" is a complete answer. **Post the fix.** If you solve it yourself, reply to your own thread. The next person searching is the entire reason discussions exist. **No recruiting, no pitching, no scraping.** Not in the channels, and not in unsolicited direct messages to people who posted in them. **Disagree with us in public.** Criticism of the product belongs in the open channel, not a private message. We would rather answer it where everyone can see the answer. ## Worth reading first Things people link to constantly The six answers that account for most of what gets asked in Discord. ### Documentation Connecting a repository, building a team, writing a deployment target, and the first request end to end. Start here ### Help centre Billing, plans, agent run allowances, and the account questions that are not really about the product. Self-serve ### Writing role contracts How to tighten a specialist, add a house rule, and stop a role doing the thing it keeps doing. Most asked ### Security and access What we can reach, what we cannot, where your code lives, and what an investigation is allowed to do. Read before deploying ### The changelog What shipped, when, and what it means for the way you already work. Updated as things land. Updated weekly ### Blog Longer pieces on gates, autonomy and what breaks when you let a team of agents near production. Occasional ## Monthly update One email a month. That is the whole offer. What shipped, what moved on the roadmap, and one thing we got wrong. No drip sequence, no sales follow-up, and no re-adding you if you leave. One email a month, unsubscribe in one click, and we never pass your address on. See the [privacy notice](https://capybari.com/privacy/). ### email ## Questions Before you post Prefer to talk privately? [Write to us](https://capybari.com/contact/) — a person replies. ### Do I need a paid plan to join? No. Discord, GitHub discussions and office hours are open to everyone, including people on the Free plan and people who have not signed up at all. What a paid plan buys is a support response time, which is a different thing. The community is not a cheaper support queue and we do not treat it as one. ### Should I report a bug here or to support? Anything affecting your production systems goes to [support](https://capybari.com/contact/?topic=Support). That route is tracked, it has a response time attached to your plan, and it does not depend on who happens to be reading Discord. Community channels are best for questions, patterns, and the ones where you are not yet sure whether it is a bug or you. ### What actually happens at office hours? An hour, monthly, with the people building the product. You bring a plan that went sideways, a role contract you are tuning, or a roadmap question. There is no presentation and no demo unless somebody asks for one. If nobody has a question we finish early, which has happened exactly once. ### Can I share my role contracts and deploy scripts? Please do. Role contracts are Markdown, deployment target commands are shell, and both are more useful shared than hoarded. Redact hostnames and anything that looks like a credential first. If you want it in the showcase, post it and say so. ### Do you answer at weekends? Sometimes, and you should not plan around it. The community runs on people choosing to be there. If something is broken at 2am, the product is designed so you do not need us: the health check fails, your rollback command runs, and an investigation opens on its own. ### Do you moderate? Yes, and quietly. Recruiting, pitching and unsolicited direct messages get a warning and then a removal. Criticism of Capybari is not moderated at all — we would rather answer it in the open channel where everyone can see the answer. ## Come and ask the awkward question The one about letting agents near your production servers. Somebody in there has already asked it, and the answer is better than a marketing page. Free on every plan · Office hours monthly · Moderated, quietly --- # Contact us URL: https://capybari.com/contact/ Send us a question about Capybari and a named human replies, usually within one working day. Or skip the form and email support, sales, security, press or privacy directly. ## Contact Talk to a person There is no chatbot on this page and no routing queue behind it. Tell us what you are trying to do and the message goes to whoever can actually answer it. A named human replies One working day, usually sooner We are in the UK ## Send a message What can we help with? Pick the closest topic and write in whatever detail suits you. Half a line is fine if half a line is the question. We use what you send here to answer you, and for nothing else. No trackers sit on this page. Read the [privacy policy](https://capybari.com/privacy/) or email privacy@capybari.com to ask for your data back. ### first_name First name ### last_name Last name ### email Work email ### company ### topic ### message ### Or email the right inbox directly Every address below reaches a person, not a routing rule. We work New York hours, so a message sent on Friday evening gets an answer on Monday. **Sales and general questions** — one working day **Support on Starter** — one working day **Support on Pro and Business** — four hours in New York working hours **Support on Free** — answered in the community Discord **Security reports** — acknowledged within one working day, every time #### Support Existing accounts, stuck runs, deployment targets, billing errors. #### Sales and pricing Plans, invoicing, and whether we can do the thing you need yet. #### Security Vulnerability reports and coordinated disclosure. Please do not open a public issue. #### Press Interviews, briefings, and the brand assets in the press kit. #### Privacy Data access, correction, export and deletion requests. ## Faster than waiting Four places that answer before we do Most questions that arrive in this inbox already have a written answer. Start here and you will probably beat our reply. ### Help centre The questions that arrive most often, answered in full: billing, autonomy levels, deployment targets, and what to do when a run stops halfway. ### Documentation Connect a repository, write a deploy command and a health check, set your first autonomy level, and read what each of the fourteen role contracts actually says. ### Community Discord, office hours and feature requests. Other teams have usually hit your problem first, and they reply at hours we do not. ## After you hit send What actually happens next Still not sure who to ask? Use the form above with **General question** and we will route it for you. ### Who reads this? A person on our team, routed by the topic you picked. You will get a reply from a named human with a working reply-to address — not an auto-responder dressed up as one. If your message lands with the wrong person, they forward it and tell you they have. ### How long will I wait? Sales and general questions: **one working day**, usually sooner. Support: **one working day** on Starter, **four hours** in UK working hours on Pro and Business. On the Free plan, the community Discord is the support channel and it is genuinely quick. If nothing has arrived by the end of the next working day, check your spam folder, then email support@capybari.com directly. ### Something is broken right now. Is this the fastest route? Check [the status page](https://capybari.com/status/) first — if the platform is degraded, it is already on there and we are already on it. If the platform is healthy and your project is not, email support@capybari.com with the project name and the run that failed. That skips the routing step. ### I have found a security problem. Email security@capybari.com rather than using this form, and please do not open a public issue. We acknowledge every report within one working day and tell you what we are doing about it. The [security page](https://capybari.com/security/) sets out our disclosure process in full. ### Will I end up on a mailing list? Only if you tick the box on the form. It starts unticked, and we leave it that way. Replying to your question is not consent to market at you, and we do not treat it as though it were. ### Can I talk to someone instead of typing all this? Not yet — we are not taking scheduled calls while we finish onboarding the first customers. [See what you actually own](https://capybari.com/signup/) instead and you will see the same thing in your own project. Old answer, for when this comes back: twelve minutes, screen shared, no sales sequence attached. It is the same people who answer this form. ### Do you have an office I can post a letter to? Not an office, no — the team is remote and there is nowhere to visit. Legal notice is served at our registered office, which is our registered agent's address in Delaware: **Dackapps LLC, 16192 Coastal Highway, Lewes, Delaware 19958, United States**. It is in the footer of every page and on the [terms page](https://capybari.com/terms/) too. Email is faster, and we read it far more often than we check the post. ## Or find out by using it The free plan answers a lot of questions faster than we can. Connect a repository, file one request, and read the plan it writes back. Manual autonomy: nothing runs until you press the button. Free · no card · Capy reads your repositories and writes you a plain-English description of your own software --- # Cookie Policy URL: https://capybari.com/cookies/ Capybari's marketing site sets no advertising or third-party cookies and loads no third-party scripts or fonts. Here is every item we store, by name, purpose and duration. ### Draft for legal review. This is a thorough outline written by the Capybari team. It has not been reviewed by a qualified solicitor and it is not legal advice. It must be reviewed and approved by a solicitor before launch. The cookie names, flags and lifetimes below have been verified against the running application. ## Cookie Policy ## 1. What cookies are A cookie is a small text file a website asks your browser to store and send back on later requests. Cookies are how a site remembers that you are signed in between one page and the next. Related technologies do similar jobs by different means. `localStorage` and `sessionStorage` keep values in your browser but are never sent to a server. They are not cookies, and we list what we use anyway, because the distinction should not be a way to avoid telling you. This policy covers **capybari.com** — the marketing site you are reading now — and the signed-in application. It sits alongside the [Privacy Policy](https://capybari.com/privacy/), which explains what we do with personal data. ## 2. What the marketing site does **This marketing site sets no advertising cookies and loads no third-party fonts.** There is one optional analytics tag, described below, and nothing else. There is no tag manager, no advertising or remarketing pixel, no social media widget, no session recorder, no A/B testing script, no chat widget and no embedded video player. **Google Analytics — on from the moment you arrive.** We would like to know which pages people find useful, and we use Google Analytics 4 for that. While the site is new it runs on every visit, and we are not currently asking first. We would rather tell you that plainly here than show you a banner that implies a choice we are not yet offering. If you accept, Google Analytics sets `_ga` and `_ga_G-40LWSGXP2R`, which distinguish one browser from another so a returning visitor is not counted twice. They expire after two years and you can clear them at any time in your browser. We turn off Google Signals and ad personalisation, so the data is not used to build an advertising profile of you, and we do not upload customer lists. Google acts as our processor and receives your IP address, which GA4 discards after using it to derive an approximate location. We said on this page that adding analytics would mean asking first, and for a period it did. It does not at the moment, and this paragraph is here so that the change is stated rather than quietly made. Consent will come back before the site is promoted anywhere; if that matters to you now, blocking `googletagmanager.com` in your browser stops the tag completely and nothing else on the site depends on it. We do keep server-side request logs — URL, timestamp, status, referrer, user agent and a truncated IP address — for security and capacity. Those are logs on our own servers, not cookies in your browser. See the [Privacy Policy](https://capybari.com/privacy/) for how long we keep them. ## 3. The two things the marketing site stores The site has a light and dark theme. When you use the theme toggle, we save your choice so the next page does not flash the wrong theme at you. That choice is stored as a value called `capybari-theme` in your browser's `localStorage`. It holds one word — the theme you picked. **It is not a cookie, it is never sent to our servers, it contains no identifier, and it cannot be used to recognise you.** If you never touch the toggle, nothing is stored and the site follows your operating system's preference. Clearing site data in your browser removes it. Nothing breaks; the site goes back to following your system preference. The second is only stored if you arrive through a campaign link — one carrying `utm_source`, `utm_campaign` or a similar tag, which is how we tell that an advertisement or a newsletter worked. Those labels are saved as `capybari-campaign` so that if you fill in a form three pages later, we can still tell where you came from. **It holds the labels we put in our own links and nothing else.** No identifier, no browsing history, no record of the pages you read. It is never sent automatically — only as part of a form you choose to submit, and if you never submit one it never leaves your browser. Arrive without a campaign link and nothing is stored at all. ## 4. Cookies used by the signed-in application Once you sign in, the application needs cookies to work. These are **strictly necessary** cookies: they are exempt from the consent requirement under the Privacy and Electronic Communications Regulations, because without them you cannot stay signed in. Cross-site request forgery is prevented with a request header rather than a second cookie, which is why only one appears below. The table below lists them, verified against the running application. All application cookies are set with the `Secure` and `HttpOnly` flags where the cookie is not read by client-side code, and with `SameSite=Lax` to limit cross-site use. The application sets no advertising cookies either. ## 5. How to control cookies You are in charge of what your browser stores. - **Block or delete cookies** in your browser settings. Every major browser lets you clear cookies and site data for one site or for all sites, and lets you block third-party cookies entirely. - **Use private browsing** to have everything discarded when you close the window. - **Clear site data** for capybari.com to remove the `capybari-theme` value along with any application cookies. Blocking cookies on the marketing site costs you nothing except your saved theme preference. Blocking them on the signed-in application will stop you signing in, because there is no other way for the application to know it is still you. Guidance for each browser is published by its maker: [Chrome](https://support.google.com/chrome/answer/95647), [Firefox](https://support.mozilla.org/kb/cookies-information-websites-store-on-your-computer), [Safari](https://support.apple.com/guide/safari/manage-cookies-sfri11471/mac), [Edge](https://support.microsoft.com/microsoft-edge). Browser "do not track" and global privacy control signals are not needed here, since we do not track you across sites, but we will honour them if we ever add anything that would. ## 6. Changes to this policy If we add anything that stores or reads data in your browser, we will update this page and the date at the top before it goes live. If the new item is not strictly necessary, we will ask for your consent first and give you a way to withdraw it. ## 7. Contact Questions about this policy, or about anything you have found in your browser that is not listed here: **privacy@capybari.com**. Last updated 5 September 2026 ## Everything we store in your browser The complete list. If you find something on capybari.com that is not on this table, tell us at privacy@capybari.com. **No advertising cookie appears on this list, on the marketing site or in the application.** The only analytics cookies are Google Analytics' own on the marketing site, set solely if you accept them — see section 2. The signed-in application carries no analytics tag at all. Cookies and browser storage used by the Capybari marketing site and application `capybari-theme` | First-party `localStorage`. Not a cookie. | Remembers whether you chose the light or dark theme. Holds one word. No identifier, never sent to a server. | Until you clear site data `capybari-campaign` | First-party `localStorage`. Not a cookie. | Only written if you arrive through a tagged campaign link. Holds the campaign labels from that link, the page you landed on and when. No identifier. Sent only with a form you submit. | Until you clear site data `aikanban_session` | First-party cookie. Strictly necessary. | Keeps you signed in to the application and links your requests to your session. `HttpOnly`, `Secure`, `SameSite=Lax`, scoped to `/`. It carries the platform's internal project name rather than the product's. | 30 days Name Type Purpose Duration --- # Customers URL: https://capybari.com/customers/ The products this company builds and runs on Capybari, and what every project gets regardless of who is running it. ## Built with Capybari The proof we can actually show you We are not going to show you a wall of other people's logos yet, because we do not have one worth showing. What we can show you is the software this company builds and runs on the platform itself — five products, planned, reviewed, deployed and investigated the way this page describes. ## Building on Capybari **Every one of these was built and is run with Capybari.** They are our own products rather than other people's, and we would rather say which than show you a wall of logos and let you assume. ## What everyone gets The same organisation, whoever is running 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, and until then this page would rather be short than padded. ### specialist roles One agent, fourteen hats, each an editable Markdown contract. ### autonomy levels Manual, Supervised, Autonomous. Every team below started at the first one. ### branch per task Its own branch in its own git worktree, so parallel work cannot collide. ### sections in every report Summary, files modified, risks, assumptions, recommendations, blockers. ## Be the first name on it 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. Free · no card · Capy reads your repositories and writes you a plain-English description of your own software --- # Documentation URL: https://capybari.com/docs/ Set up Capybari end to end: create an account, connect a git repository, add a deployment target over SSH, assemble your team and file your first request. ## Documentation Get started with Capybari One request, planned, built, reviewed, deployed and reported on. Start here, then use the navigation for the detail. Capybari runs an engineering organisation on your repositories and ships the result to your servers. This page takes you from an empty account to one request that has been planned, built, reviewed, deployed and reported on. Work through it in order. Allow about thirty minutes, most of which you spend watching. ## Before you start Have these ready: - A git repository Capybari can clone, plus an access token if it is private. - A server you can reach over SSH, if you want to deploy. Skip it for now if you do not — planning, building and review all work without one. - A terminal, for two copy-and-paste steps. ## Create your account 1. Register at [capybari.com/signup](https://capybari.com/signup/) with your work email address. 2. Confirm the address from the message we send you. 3. New accounts are reviewed before the first sign-in. You get an email when yours is ready. 4. Sign in and choose **New project**. Give it a name — the name becomes the project slug used for its checkout paths, so keep it short. A project is the unit that owns everything else: its repositories, its team, its deployment targets, its board and its autonomy level. Most teams run one project per product, and agencies run one per client. ## Connect a git repository Open **Project settings → Repositories** and choose **Add repository**. | Field | What to put in it | | --- | --- | | Name | A short label, such as `api` or `web`. Used in branch and worktree paths. | | Repository URL | Any git remote Capybari can reach over HTTPS or SSH. | | Access token | A personal access token with read and write scope. Required for private repositories. Stored encrypted. | | Default branch | Leave blank and Capybari detects it from the remote. | Capybari clones the repository when you save. If the clone fails you get the git error back word for word, which is usually enough to tell a wrong URL from a wrong token. The first repository you add becomes the project's primary repository: the Project Manager plans in it, and tasks default to it. You can add more repositories at any time. Tasks are assigned to one repository each, so a task in `web` never touches the worktree of a task in `api`. ## Add a deployment target A deployment target is a server you own, described precisely enough that an agent can ship to it and put it back the way it was. Open **Project settings → Deployment targets → Add target**. Choose a target type first: - **SSH host** — Capybari merges, connects over SSH and runs your commands. Use this one for a real deploy. - **Merge and push only** — Capybari merges the approved branches and pushes. Your own pipeline takes it from there. - **Download only** — Capybari produces a build artefact you download by hand. For an SSH target, fill in the host, port, username and these four fields. **Deploy path.** The directory the deploy runs in. Capybari runs your deploy command as `cd '/srv/orderly/app' && your-command`, so write the command as though you are already standing in that directory. **Deploy command.** One shell command, or several joined together. It must be safe to run twice. ```bash git pull --ff-only origin main && \ docker compose build --pull web && \ docker compose up -d --remove-orphans && \ docker compose exec -T web ./manage.py migrate --noinput ``` **Health check.** Either an HTTP check or a command check. - *HTTP* — give a URL. Any status from 200 to 399 passes. Anything else fails, and the status code and the first part of the body are recorded on the run. - *Command* — give a shell command. Exit code 0 passes. **Rollback command.** This is the field that lets you sleep. Capybari records the commit that was live the last time a health check passed, and substitutes it into `{sha}` when a rollback is needed. ```bash git reset --hard {sha} && docker compose up -d --remove-orphans ``` ### Add the deploy key to your server Capybari generates an ed25519 keypair when you save the target and keeps the private half encrypted. You are never asked to hand over a private key. Copy the public key it shows you onto the server, as the user you gave in **Username**: ```bash # On your server, as the deploy user mkdir -p ~/.ssh && chmod 700 ~/.ssh echo 'ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBq7T2m0nJ4pW8Xh1sD9vK3rY6fL0cN5uE2aZ8gQwR4t capybari-deploy-production' >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys ``` Now press **Test connection**. The test opens an SSH session and checks that the deploy path exists and is writable. Until it passes, the target cannot be deployed to at all — a target you have not proved you can reach is not a target. ## Choose the hats There is one agent, Capy. What you configure per project is **which hats it may put on** — which expertise it brings, and the contract governing each. Fourteen are available: | Domain | Hats | | --- | --- | | Assists you | Capy Executive Assistant, Capy Full Execution | | Product | Product Owner, Project Manager | | Software | Architect, Developer, QA Engineer, Security Engineer, iOS Developer, Android Developer | | Design | UI/UX Designer | | Operations | DevOps Engineer | | Marketing | Marketing Manager, Product Marketing Manager | Start with five: Project Manager, Developer, QA Engineer, Security Engineer and DevOps Engineer. That covers planning, building, checking and shipping. Add the rest as the work demands them. Two things to know about a partial set: - Work planned for a hat you have not enabled is done under the closest one that covers the capability, and the substitution is recorded on the task. If nothing covers it, the task falls back to the Project Manager hat. A task is never dropped for want of a job title. - Every hat is governed by a Markdown contract you can read and edit. Open a role and tighten its rules if your codebase needs it. Tick **Requires review** on any role you want a human gate behind. Work that depends on a task owned by that role stops until you approve it — at every autonomy level, with no exceptions. ## Set autonomy to Manual Open **Project settings → Autonomy** and choose **Manual** for your first request. | Level | What happens on its own | | --- | --- | | Manual | Nothing. You start planning, you approve the plan, you dispatch the work, you press deploy. | | Supervised | Planning starts when you file the request, and approved work dispatches itself. Deployment stays yours. | | Autonomous | Planning, dispatch and deployment all proceed without you on healthy, unblocked work. | Autonomy governs how much of a healthy pipeline you approve by hand. It never changes what an agent is allowed to do, and it never suppresses a review gate or a genuine escalation. ## File your first request Choose something that has been on your list for a month and is small enough to read in one sitting. Press **New request** on the board. - **Title** — one line, in your own words. "Card payments fail for European customers" is a fine request. - **Description** — anything you know. Error messages, a customer's exact words, the file you suspect. It is all useful and none of it is required. - **Type** — feature request, improvement, investigation, bug fix, deployment or other. - **Priority** — urgent, high, medium or low. This orders the board. Save it, then press **Start planning**. ## Read the plan The Project Manager reads your repositories and comes back with a plan. It has three parts: 1. A **plan summary** in plain English: what it intends to change and why. 2. A list of **tasks**, each with a task code, an owning role and a spec file. 3. A **dependency graph** — every task lists the tasks it waits for, so you can see what runs in parallel and what queues behind a decision. Read the summary first. If it has misread you, press **Re-plan** and say what it got wrong; your feedback goes to the Project Manager and it plans again. You can do this as many times as you need. Nothing has run yet. ## Approve the plan When the plan is right, press **Approve**. You can untick individual tasks before you approve if you want a smaller first slice — unticked tasks are skipped, not deleted. At Manual autonomy the tasks now sit ready. Dispatch them yourself. ## Watch the run Every task claims its own branch in its own git worktree, so parallel tasks cannot see each other's half-finished work and none of it touches your default branch. Open a running task to watch it live. The stream shows the commands the agent runs and the output it gets back, as it happens. Three things can interrupt it, all of them on purpose: - **The agent asks you a question.** When a specialist hits genuine ambiguity it stops and asks rather than guessing. Answer in the task and it continues. - **A review gate holds.** A task owned by a role marked *requires review* waits for your approval before its dependents start. - **A design preview appears.** Front-end tasks produce a shareable preview link so you can look at the change before it merges. ## Review the report Every task ends with a structured report, in the same shape every time: - **Summary** — one or two sentences on what was done. - **Files Modified** — each path, with what changed in it. - **Risks** — what might bite, in the author's own judgement. - **Assumptions** — what it decided for itself when you had not said. - **Recommendations** — follow-up worth doing. - **Blockers** — what stopped it, if anything did. Read *Risks* and *Assumptions* first. They are where the disagreements live. If the report is wrong, give the task feedback and send it back. If it is right, approve any tasks waiting on review, then press **Merge and deploy** and pick your target. Capybari merges the approved branches, records a merge summary, runs your deploy command, runs your health check, and — if the check fails — runs your rollback command against the last commit known to be healthy and opens an investigation. You now know the whole loop. Everything after this is the same five moves at a larger size. ## Where to go next - Turn autonomy up one level when the plans stop surprising you. Most teams take about three weeks to reach Supervised. - Add the roles you left out, starting with QA Engineer. - Read the role contracts and tighten the ones that matter to your codebase. ## Two safeguards Read these before you connect a server ### You never hand over a private key. Capybari generates the deploy keypair itself and keeps the private half encrypted. You copy the public half onto your server, and you can revoke it there at any time by deleting one line. ### A target with no rollback command cannot roll back. Automatic rollback runs the command you supply against the last commit that passed a health check. Leave the field empty and a failed deploy stays failed until you intervene. ## Troubleshooting When setup does not go to plan The four things that go wrong most often during installation, and what to do about each. Nothing here matching? [Search the help centre](https://capybari.com/help/) or [ask us directly](https://capybari.com/contact/). ### The connection test fails with Permission denied (publickey). The public key has not reached the account you named in **Username**. Check, in this order: 1. The whole key is on **one line** in that user's `~/.ssh/authorized_keys`. A key split across two lines is the most common cause. 2. `~/.ssh` is mode `700` and `~/.ssh/authorized_keys` is mode `600`, both owned by the deploy user. 3. `sshd_config` has `PubkeyAuthentication yes`, and any `AllowUsers` or `AllowGroups` line includes your deploy user. Then run `sudo journalctl -u ssh -n 50` on the server while you press **Test connection** again. The refusal reason is in there. ### The test says the deploy path is not writable. The test checks two things: that the deploy path exists, and that the SSH user can write to it. Create the directory and hand it over: ```bash sudo mkdir -p /srv/orderly/app sudo chown -R deploy:deploy /srv/orderly/app ``` A target cannot be deployed to until this test has passed once. That is deliberate. ### My repository will not clone. Capybari clones the repository the moment you save it, and gives you the git error back word for word. - **Authentication failed** — the token is missing, expired, or lacks repository scope. Fine-grained tokens also need the specific repository selected. - **Repository not found** — usually the URL is correct but the token cannot see that repository. Check the token's owner, not the URL. - **Host key verification failed** — you gave an SSH remote. Use the HTTPS URL with a token instead. ### The deploy command works when I run it by hand but fails from Capybari. Capybari runs your command over a non-interactive SSH session as `cd '/your/deploy/path' && your-command`. Your shell profile is not loaded, so anything that lives in it is missing. Use absolute paths to binaries — `/usr/bin/docker`, not `docker` — or load what you need inside the command itself. Test it the same way to be sure: ```bash ssh -o BatchMode=yes deploy@your-host "cd '/srv/orderly/app' && your-command" ``` ### The health check times out or returns nothing. An HTTP health check passes on any status from 200 to 399 and fails on everything else, recording the status code and the start of the body on the run. A timeout with no status usually means the URL is not reachable from outside your network. Point the check at an endpoint that is cheap, public and honest — one that touches the database if a broken database should fail the deploy. ### My first plan came back thin or wrong. Press **Re-plan** and say what it missed. Your feedback goes to the Project Manager, which plans again with it in hand. Nothing has run at this point, so there is nothing to undo. Plans improve most from two things: a description that names the file or screen you mean, and a repository whose conventions are written down somewhere the agents can read. ### I approved the plan and nothing happened. At **Manual** autonomy, approving a plan does not dispatch it. Approval and dispatch are separate deliberately. Open the request and dispatch the tasks, or move the project to **Supervised** so approved work dispatches itself. If tasks are dispatched but sitting still, check whether one is waiting on a dependency or on a role you marked as requiring review. ### A task is stuck asking me something. That is the design. When a specialist hits genuine ambiguity it pauses and asks rather than guessing. Open the task, answer the question, and the run continues from where it stopped. ## Set it up in half an hour Connect one repository, add five roles, leave autonomy on Manual and file one request. You can add the server later. No card required · Your repositories, your servers · Export everything, any time --- # Feature catalogue URL: https://capybari.com/features/ Every Capybari capability in one place: planning and task graphs, isolated builds, review gates, SSH deployments with rollback, investigations, autonomy levels and the board. ## Features Everything in the box, grouped sensibly. Six groups, in the order the work moves through them: planning, building, review, deployment, control and visibility. If a capability is not on this page, we have not built it — the things we intend to build are dated on [the roadmap](https://capybari.com/roadmap/). No card required Everything below is shipped today ## Group one Planning and coordination The part a code generator skips. Work is read, understood and ordered before anything is written. ### The request board File work as a request with a type and a priority. Reorder it, park it, archive it. The board is the single place the state of everything lives. ### Plain-English plans The Project Manager turns a request into a plan summary you can read in a minute — what it intends to do and why, before it does any of it. ### Task dependency graphs Tasks carry a depends_on relationship, so a migration lands before the code that reads from it and unrelated work runs side by side. ### Owners on every task Each task is assigned to the role that should hold it: architect, backend developer, database engineer, QA engineer, and the rest of the team. ### Approval gates Plans wait for your approval unless you have deliberately raised the autonomy level. Approve, edit, or send it back with what it missed. ### Talk to the Project Manager Chat about a project when you are still working out what you want. The conversation can become a request when it is clear enough to plan. ### A director brief Capy frames a request against the project as a whole before the tasks are drawn up, so plans are not written in a vacuum. ### Capability substitution Work planned for a role your team does not have is reassigned to a role that can cover it — and the substitution is recorded, never silent. ### Projects and repositories A project holds connected git repositories and its own set of hats. Work spanning a front end and an API is still one request. ## Group two Building Parallel work that cannot collide, because no two tasks share a working directory. ### A branch per task Every task runs on its own branch, cut from the base branch you nominate, and merges back into it once the gates pass. ### An isolated git worktree Each branch gets its own worktree on disk. One specialist cannot read another's half-finished edit, because it is not in its directory. ### Parallel dispatch Independent tasks run at the same time. Dependent tasks wait, visibly, until the work they need is finished. ### Fourteen specialist roles From Architect and Security Engineer to iOS and Android Developer. Staff a project with the roles it needs and leave out the rest. ### Agents that ask questions A specialist facing genuine ambiguity pauses mid-run and puts the question to you, rather than picking an answer and building on it. ### Design previews Front-end tasks produce a shareable preview link, so the people with opinions can look while changing it is still cheap. ### Cheap abandonment Killing a task deletes a branch. Nothing has reached your default branch, so there is nothing to unpick. ### Existing codebases Role contracts instruct every specialist to read your conventions, make the smallest safe change, and reuse patterns rather than invent new ones. ### Model and effort per run Override the model and the effort level for a project, or for the single request that deserves more thought than the rest of the queue. ## Group three Review and quality Gates before speed. Governance roles read the work rather than produce it, and they can reject. ### Roles that require review Flag any role as requiring human review. Dependent work then stops until a person approves — at every autonomy level, with no override for urgency. ### Structured completion reports Every task ends with a summary, files modified, risks, assumptions, recommendations and blockers. The same shape every time, so it is skimmable. ### Code review as a role Under the QA hat, Capy reads the diff against your contracts and can send the work back rather than shipping it. The review that is genuinely independent is yours, at the gates you set. ### A security pass per request The Security Engineer reviews exposure on the work in front of it. Not a scan bolted on at the end of the quarter. ### QA as a distinct role The QA Engineer checks the work against what the request actually asked for, which is a different question from whether the code is good. ### Architectural review The Architect reviews shape and fit before and after the build, so a fast change does not quietly become a structural one. ### Blockers surfaced early A task that cannot finish says so in its report, with the reason, instead of producing something plausible and leaving you to find out. ### Nothing merges quietly You see the diff, the reviewer's verdict and the security note before the branch goes anywhere near your base branch. ### Editable role contracts Every role's behaviour is a Markdown document. Tighten a standard, loosen one, or write the rules your codebase already lives by. ## Group four Deployment and operations Past the pull request, which is where most of this category stops. Your servers, your commands. ### Deployment targets over SSH An SSH host with a deploy path. No agent is installed on your machine; Capybari runs the commands you gave it and nothing else. ### Your deploy command Whatever your deployment already is — a script, a compose file, a systemd restart — stays what it is. We run it, we do not replace it. ### Health checks A deploy is not called good because it finished. It is called good because your health check came back healthy. ### Automatic rollback A failed health check runs your rollback command and restores the last commit known to be healthy, without waiting for anyone to wake up. ### Diagnostics on demand A diagnostics command you define gives an investigating agent something reliable to run when it needs to know what the host thinks is happening. ### Deployment runs, in phases Merge summary, deploy output and health-check output are kept with the run, so the post-mortem has something real to read. ### Production investigations A failed run opens an investigation with an agent assigned. Access is read-only by default and only becomes write access if you grant it. ### Follow-up requests An investigation can open the request that fixes the problem, linked back to the run it came from, so the history reads in order later. ### Merge into your history One branch per task, one report per branch. Your git log stays something a human can still read next year. ## Group five Control and configuration Every one of these is yours to set, and every one of them is reversible. ### Three autonomy levels Manual, Supervised and Autonomous, set per project. Start where nothing runs without you and climb only when the plans stop surprising you. ### Per-project teams Choose which specialists exist on which project. A marketing site does not need a database engineer; your billing service probably does. ### Contracts you can edit Role behaviour is Markdown, versioned and readable. Change it and the next run follows the new contract. ### Investigation access levels Read-only by default. Raising an investigation to write access on a production host is a deliberate act you take one investigation at a time. ### Model and effort overrides Set the model and effort for a project, or override both for a single request. Cheap work stays cheap; hard work gets the headroom. ### Base branch control Tasks branch from the base you nominate and merge back into it. Your branching model does not have to change to suit ours. ### Owner and admin roles Capybari is multi-tenant with owner and admin roles, so an organisation can decide who may change a deployment target and who may not. ### Usage per agent account Agent accounts track their own usage, so cost is attributable to the work that caused it rather than to a single line on an invoice. ### An admin dashboard Organisation-level administration in one place: members, projects and the accounts running your work. ## Group six Visibility Show the work. An organisation you cannot observe is not one you can trust, however well it behaves. ### The board Requests, planned tasks, running work, review gates, deployment runs and open investigations, in one view rather than five tools. ### Live run streaming Watch a task as it works: the commands it runs and the output it gets back, streamed while it happens rather than summarised afterwards. ### Reports you can skim Summary, files modified, risks, assumptions, recommendations, blockers. The same six headings on every task, which is what makes them fast to read. ### Plan summaries The intended shape of the work in prose, on the board, before any of it is built. ### Dependency state See which task is waiting on what. Work that has stalled looks stalled, instead of looking like nothing. ### Shareable design previews Send a preview link to someone who has never seen the board and has no intention of learning it. ### Deployment history Every run keeps its phases and its output, including the ones that rolled back. Especially the ones that rolled back. ### Investigation summaries A written cause and resolution you can read, forward, or paste into the update you owe a customer. ### Usage you can attribute Runs are the unit of work and the unit of billing, so what you spent maps to what got done. ## In context Capybari, an AI coding assistant, and a contractor Three different things that all end with code in your repository. Here is where each of them actually helps — including the rows we lose. The last three rows are the ones we lose, and they stay in the table. A comparison with nothing but ticks in our column would tell you more about our marketing than about our product. Cursor and its relatives are genuinely excellent at the thing they do — they are complementary to this, not competitive with it. Capabilities compared across Capybari, AI coding assistants and contractors Plans the work before writing it You plan; it types A dependency graph across parallel tasks In someone's head Isolated branch and worktree per task Whatever they do locally Review by a role that can reject the work If you hire a second one A security pass on every request Rarely in scope Deploys to your own servers Health check with automatic rollback Only if you asked for it Investigates a production failure at 3am During office hours Runs while nobody is at a keyboard Needs you in the chair Sits in your editor as you type No — different job Judgement about your market and your customers **No.** It knows the repository, the request and its contracts. That is all Yes, and it is why you hire people Ready for enterprise procurement **Not yet** — see [pricing](https://capybari.com/pricing/) for the list Capybari AI coding assistants Hiring contractors ## Questions What people ask about the list above Looking for something not listed? [Tell us what it is](https://capybari.com/contact/). ### Which of these need a server connected? Only deployment, automatic rollback and production investigations. Planning, building, review gates, reports and design previews all work with a git repository and nothing else. Plenty of teams run Capybari to the merge and handle deployment themselves. ### Do I have to use all fourteen roles? No. Staff a project with the roles it needs. Work planned for a role that is not on the team is reassigned by capability substitution, and the substitution is recorded so you can see it happened. ### Can I change what a reviewer enforces? Yes. Each role's contract is a Markdown document you can edit. If your codebase has a convention worth defending, write it into the QA Engineer's contract and it will be defended on every task. ### Is there an API? A public API is on [the roadmap](https://capybari.com/roadmap/) rather than in the product today. We would rather say that plainly than let you find out after you have signed up. ### How does this compare on price to a contractor? We meter agent runs — one task executed end to end by one specialist — because that is the thing that produces something. [The pricing page](https://capybari.com/pricing/) shows what each tier holds. The work itself runs on your own subscription at no extra cost, or on credits you buy before they are spent. ### What about SSO, SOC 2 and an uptime SLA? We do not have them. They are on the roadmap with the quarters we expect them in, and the Enterprise section of the pricing page lists exactly what is missing. If procurement needs those today, we are not your platform yet. ### Where do I see all of this working together? [The platform page](https://capybari.com/platform/) walks one request through all six stages in order, and [the agent team page](https://capybari.com/ai/) explains how the specialists divide the work between them. ## Read the list, then file something Connect one repository and file one request. The free plan runs at Manual autonomy, so nothing on this page happens until you press something. Free · no card · Capy reads your repositories and writes you a plain-English description of your own software --- # Help centre URL: https://capybari.com/help/ Answers on projects, repositories, autonomy, review gates, deployment, rollback, investigations and billing — plus how to reach a person. ## Help centre Something not behaving? Start with the category that matches what you were doing. If none of it helps, a person answers every message — within one working day, and faster on the paid plans. ## Browse By what you were doing ### Getting started Creating an account, your first project, connecting a repository, filing your first request. ### Projects & repositories Connecting git remotes, tokens and keys, multiple repositories, verifying a connection. ### The agent team Adding roles, editing role contracts, capability substitution, model and effort defaults. ### Autonomy & approvals Choosing a level, review gates, approving plans, answering an agent's question. ### Deployment & rollback Configuring a target, health checks, why a deploy failed, what rollback did. ### Investigations What opens one, read-only versus write access, reading a resolution, follow-up requests. ### Billing & plans Credits, what a run costs, changing plan, invoices, cancelling. ### Account & security Access, credential storage, data handling, deleting your data. ## Most asked The questions support actually gets ### Why is my task waiting instead of running? Three usual causes, in order of frequency: 1. It declares a **dependency** that has not completed. The board shows what it is waiting on. 2. It is behind a **review gate** and needs your approval. 3. The project has hit the **concurrent-run limit** for your plan — one on Free, three on Starter, ten on Pro. ### How do I stop a run that is going wrong? Cancel the task from the board. The run stops, and the branch and worktree are left in place so you can see exactly what it had done before you intervened. Dependent tasks stay blocked until you retry or re-plan. ### An agent asked me a question. What happens if I ignore it? Nothing bad, and nothing at all. The task sits in an awaiting-input state indefinitely, its dependents stay blocked, and no work is guessed at. An agent will not invent an answer to get unstuck. ### The plan it wrote is wrong. What are my options? Reject it and say what it missed — planning runs again with your note. You can also edit the task list directly before approving, or delete individual tasks. Nothing dispatches from a plan you have not approved. ### My deploy failed and rolled back. Where do I look? Open the deployment run. It holds the merge summary, the deploy output, the health-check output, and the rollback output, in order. An investigation will also have opened automatically — that is usually the faster read, because an agent has already gone through the logs and written up what it found. ### Why did a task get reassigned to a different role? Capability substitution. The work was planned for a role that is not on your project team, so it went to the member whose capability profile covers it. The substitution is recorded on the task — it is never silent. Adding the missing role stops it happening again. ### Can I stop it touching a particular file or directory? Yes — put it in the role's contract or the project rules. Every specialist reads its contract before it plans, and "never modify X" is a normal thing to write there. ### I have run out of agent runs. What happens now? On the free plan, work stops until the month rolls over. On paid credits, work stops and waits until you top up or connect a subscription of your own. Nothing is lost, and queued work resumes on its own once there is something to run it on. ### How do I export my data? Your code is already yours — it is in your repositories, on branches, in your git history. Requests, plans, tasks and completion reports export from project settings. There is no retention hold and no export fee. ### Something is broken and it is not my project. Check the [status page](https://capybari.com/status/) first. If it is green and you still cannot work, [tell us](https://capybari.com/contact/?topic=Technical+support) — include the project and the request or task reference and we can look at the run directly. ## Support What you can expect from us ### Free Community support via Discord and the feature-request board. We read it; we do not promise a response time. ### Starter Email support with a one-working-day target, New York hours. ### Pro Priority email support with a four-hour target during New York hours. ### Business Priority support plus a named contact and onboarding help for the first project. ### Anything security-related Goes to security@capybari.com on every plan, including Free, and is triaged the same day. Security is not a paid tier. ### What we will not do Route you through a chatbot, ask you to fill in a form to reach a human, or close a ticket because it went quiet. ### Reaching a person quickly Include the project name and the request or task reference — for example REQ-142 or T-04. With that we can open the exact run you are looking at instead of asking you three clarifying questions first. ### Found a security problem? Email security@capybari.com rather than using the contact form, and please do not open it publicly. Our disclosure process, including safe harbour, is on the [security page](https://capybari.com/security/). ## Still stuck? Tell us what happened and what you expected instead. A person reads it. --- # Integrations URL: https://capybari.com/integrations/ GitHub, GitLab, Bitbucket or any git remote — or upload a folder or zip. Deploy to servers you control over SSH, bring your own model keys. ## Integrations It works with what you already have Capybari does not want to own your git host, your servers or your model provider. It connects to them. Everything below is marked **shipped** or **planned** — we would rather lose a sale than have you find out after signing. ## Missing something you need? [Tell us](https://capybari.com/community/) — the feature request board is genuinely read, and roughly a third of the roadmap started there. ### Git hosting — shipped Any git remote Capybari can authenticate to — and, for code that is not on a host at all, an uploaded folder or zip that Capybari turns into a repository. Tokens and keys are stored encrypted. Work happens on branches inside **your** repository, never on a copy in ours. #### GitHub #### GitLab #### Bitbucket #### Gitea / Forgejo #### Any git over SSH #### Folder or zip upload #### Multiple repos per project ### Deployment targets — shipped A target is a host reached over SSH, plus four things you write: a deploy path, a deploy command, a health check and a rollback command. Because the commands are yours, the shapes below are configurations rather than separate integrations — which is why there is no waiting list for your stack. #### SSH host #### systemd service #### Docker Compose #### Static site build #### PostgreSQL #### MySQL #### HTTP health check #### Command health check #### Rollback command #### Diagnostics command ### Models and agent accounts — shipped Agents run on large language models. Capybari supplies capacity on every plan and tracks usage per account. On **Business** you can bring your own provider keys, which means your prompts go to your own account under your own agreement. #### Managed capacity #### Bring your own keys #### Per-role model defaults #### Per-request overrides #### Usage tracking #### Concurrency limits ### Notifications — partly shipped Email and in-application notification are shipped. **Slack, Discord and outbound webhooks are planned for Q3 2026** and are not available today. #### Email #### In-app activity #### Live run stream #### Slack #### Discord #### Outbound webhooks ### Planned — not available yet Listed so you can plan around them, not so you can buy them. Nothing in this group works today. Quarters are intentions, not commitments — see the [roadmap](https://capybari.com/roadmap/). #### Public REST API v1 #### Native GitHub app #### Native GitLab app #### Jira #### Linear #### PagerDuty #### Sentry #### Terraform provider ## Setting one up What connecting a server actually involves ### Four commands and a key There is no agent to install on your server and no daemon to run. Capybari generates a key pair, you install the public half, and it connects over SSH like any other client. #### A deploy path where your code lives on the host. #### A deploy command whatever you already run by hand today. #### A health check an HTTP endpoint or a command. Without one, a target can never be marked healthy — which is what makes rollback mean something. #### A rollback command run automatically when the health check fails. #### A diagnostics command optional, and the first thing an investigation reads when something breaks. ## Extending it Building your own Three honest answers about integrating Capybari with something we do not support. ### The deploy command is the extension point Anything you can express as a shell command on your own host is already supported. Most requests we get for a new integration turn out to be a three-line deploy script. ### The public API is planned A documented REST API with webhooks is on the roadmap for Q4 2026. Today's endpoints exist to serve the application and are not stable enough to build against. ### Ask before you build If you are about to write something substantial around Capybari, talk to us first. We would rather shape the roadmap around it than watch you maintain a workaround. ## Questions Before you connect anything Something missing? [Ask us](https://capybari.com/contact/) or [request it](https://capybari.com/community/). ### Does Capybari need a GitHub app installed? No. Capybari works with any git remote it can authenticate to, using a token or SSH key you provide. Native GitHub and GitLab apps are on the roadmap for Q3 2026, but they are a convenience — not a requirement. ### Can I deploy somewhere that is not an SSH server? A deployment target is a host reached over SSH, with a deploy path and commands you write. Because the commands are yours, that covers most things — a systemd service, a Compose stack, a static build, a migration runner. If your platform has no SSH entry point, Capybari cannot deploy to it today. You can still use it for planning, building and review, and deploy yourself. ### Where are my git tokens and SSH keys stored? Encrypted at rest, scoped to the project that owns them, and never written into an agent's prompt or a task log. The [security page](https://capybari.com/security/) sets out the handling in full. ### Can I use my own model provider account? Yes, on every plan including Free — bring your own keys and your prompts go to your account under your own agreement with that provider. On other plans, capacity is included and metered as agent runs. ### What happens if a deployment target stops responding? The deployment run fails at the phase it reached, your rollback command runs if the failure came after a deploy, and an investigation opens. The target records when its connection was last verified, so a target that has quietly gone stale is visible before you need it. ### Do you support monorepos? Yes. A project can connect several repositories, and a task is scoped to the repository it needs — so a monorepo and a set of separate repositories both work. ## Connect a repository and see The free plan connects one repository and needs no card. You can leave the server disconnected until you trust it. No card required · Deploys to your own infrastructure · Export everything --- # Partners URL: https://capybari.com/partners/ Run Capybari for your clients, connect your tooling to it, or refer teams who need an engineering organisation they cannot staff. Three partner types, one application. ## Partners Bring the engineering organisation with you. Agencies run Capybari for their clients. Tool builders connect it to the git host, the server and the alerting their users already have. Consultants and creators refer the teams they cannot take on. Three ways in, one form. No fee, no minimum commitment You keep the client relationship Reviewed within five working days ## Three kinds of partner Find the one that describes you You can be more than one. Plenty of agencies implement for some clients and refer the rest. ### Implementation partners You are an agency, studio or consultancy, and you run Capybari **for** your clients. You set up their projects, assemble the right specialist team per project, write the role contracts to match their conventions, connect their deployment targets, and stay on to operate it. You own the engagement and set your own rates. We give you per-client project isolation, per-client deployment targets and an audit trail you can show them. ### Technology partners You build something Capybari should meet in the middle — a git host, a hosting or infrastructure platform, a monitoring or alerting product, a chat tool where approvals should land. We work on branches in the customer's own repositories and deploy to SSH hosts they control, so the useful integrations are the ones already sitting either side of that. Bring the use case and we will bring an engineer. ### Referral partners You advise, teach or write for people who keep describing our exact problem — more roadmap than hours, no room to hire a reviewer, a security engineer and a DevOps engineer. You introduce them; we do the rest, and you stay in the loop on how it went. There is no referral programme to read yet — when there is, it will be published in full rather than negotiated privately, one rate for everybody. ## Getting started Four steps, no procurement theatre Most partners are running their first client project inside a fortnight. ### Apply Fill in the form below. Tell us who you work with and what you would build. Two paragraphs is plenty. ### Talk it through A 30-minute call about the work in front of you, not a qualification script. We say no clearly when it is not a fit. ### Run a real project Bring one live piece of client work. We help you set up the project, the team and the first deployment target, and we watch the first deploy with you. ### Go on the record Signed agreement, partner listing, referral tracking if you want it, and a named contact who answers you directly. ## What partners get The practical list What we intend to offer. None of it is contracted yet, and the commercial terms deliberately are not listed at all. **A named contact** who knows your accounts, rather than a shared inbox **Onboarding for your team** — a working session on projects, role contracts, autonomy levels and deployment targets **Per-client project isolation** and per-client deployment targets on the Business plan **An audit trail you can hand to a client** — every plan, diff, deploy log and investigation, exportable **Referral commission** on the accounts you introduce, on the published terms **A listing in the partner directory** with your specialisms and the industries you serve **Early access** to features on the roadmap, and a route to say they are wrong before they ship **Co-marketing when there is something true to say** — a case study your client has approved, not a logo swap **Sandbox projects** for demonstrations, so you are never showing a client your other client's board **Direct escalation** into engineering for anything blocking a client deploy ## Apply Tell us what you would build One form for all three partner types. A person reads it, and we aim to reply within five working days. We use what you send here to answer you and nothing else. See the [privacy notice](https://capybari.com/privacy/). ### name Your name ### email Work email ### company ### website ### partner_type Partner type ### message What would you build with it? ### Before you write Applications that get a fast yes tend to have these things in them. A live project you could start with, not a hypothetical one The stack and git host your clients actually use Whether your clients deploy to their own servers today How many projects you would expect to run in parallel Anything you think we are missing — we would rather hear it now #### Partnerships We reply to every application, usually within two working days #### Everything else General enquiries, support and sales ## Questions What partners ask first Something not covered? [Ask partnerships directly](mailto:partners@capybari.com). ### Does becoming a partner cost anything? No. There is no application fee, no annual partner fee and no minimum commitment. You will need a Capybari account to run projects — whichever plan suits the work, and the [Business plan](https://capybari.com/pricing/) is the one built for multi-client use. ### Who owns the client relationship? You do. Implementation partners contract with their own clients, set their own rates and keep their own commercial terms. We do not approach your clients directly without asking you first, and we do not take over an account you introduced. ### Can I be more than one type of partner? Yes, and most agencies are. You implement for the clients who want it run for them, and you refer the ones who would rather run it themselves. Tick **More than one of these** on the form and we will set both up. ### What does an implementation partner actually do? Set up the client's project and connect their repositories. Assemble the specialist team the work needs. Edit the role contracts so the agents follow that codebase's conventions. Configure the deployment target — deploy command, health check, rollback command. Then operate it: approve plans, hold the review gates, and raise the autonomy level as the client's confidence grows. ### What integrations are you actually looking for? Anything sitting immediately either side of the pipeline. Git hosts, because we work on branches in the customer's own repositories. Hosting and infrastructure, because deployment targets are SSH hosts the customer controls. Monitoring and alerting, because that is what tells you a health check should have failed. Chat tools, because approvals and mid-run questions want somewhere to land. See the [integrations page](https://capybari.com/integrations/) for what exists today and the [roadmap](https://capybari.com/roadmap/) for what is queued. ### Can I white-label Capybari? Not today. You can run it for a client under your own service brand and hand them the audit trail, but the product itself is not re-brandable and we are not going to pretend otherwise. If that is a blocker, say so on the form — it is useful evidence. ### How do referral commissions work? They do not yet. We have not agreed a rate, a cookie window, a payout schedule or a minimum, so there is nothing to publish and we are not going to invent terms to fill a page. Introduce someone anyway and say so on the form. We would rather settle it with the people who actually did it than write a rate card nobody has tested. ### My clients will not let an agent near production. Now what? Then do not point it at production. Start at **Manual** autonomy, where nothing runs until someone presses the button, and connect no deployment target at all. Plenty of teams run Capybari for planning, building and review only. Deployment is a thing you switch on later, if ever. ## Run one client project through it The fastest way to know whether this is worth a partnership is to put one real piece of client work through the board and watch what the plan looks like. No fee · No minimum commitment · Reviewed within five working days --- # Platform URL: https://capybari.com/platform/ The full path from a filed request to a deployed change: planning, approval, isolated builds, review gates, deployment, rollback and investigation. ## The platform One request. Six stages. No war room. This is the whole pipeline, in order, with nothing hidden. A request lands on the board. Capy plans it. You approve. It builds each task on an isolated branch, checks the work against what you asked, and ships it to your server and watches the health check — and puts it back if the check fails. Manual autonomy until you change it Your repositories, your servers Every stage visible on the board ### branch and worktree per task Parallel work that cannot collide, and abandons cleanly. ### hats it can wear One agent, and the expertise it brings to each piece of work. ### autonomy levels Manual, Supervised, Autonomous. You move when you're ready. ### silent merges Anything marked for review stops until a human approves it. ## Request to production What actually happens, stage by stage The pipeline is the same every time. What changes between projects is how many of these stages need your hand on them. ### You file a request Write what you want in the language you would use with a colleague. A request has a type, a priority and a position on the board — you can reorder it, park it, or archive it when it stops mattering. It belongs to a project, and a project holds the git repositories and the hats Capy may put on for the work it holds. **No specification required.** "Card payments fail for European customers" is a request. So is "move the invoice PDF job off the web server". **Types and priorities** sort the board so the important thing is not the thing at the bottom. **Talk it through first** if you'd rather — chat with the Project Manager about the project and turn the conversation into a request when it's clear. **One project, many repositories.** Work that spans a front end and an API is still one request. ### Capy plans it Under the Project Manager hat, Capy reads the request and your connected repositories, then writes a plan: a summary in plain English, a set of tasks, an owner for each task, and a `depends_on` graph saying what has to happen before what. Nothing has been built yet. This is the cheapest moment to disagree. **Owners, not guesses.** Each task is assigned to the role that should hold it — architect, backend developer, database engineer, QA. **A dependency graph**, so a migration lands before the code that reads from it, and independent work runs side by side. **Written for a human.** The plan summary is prose you can read in a minute, not a JSON blob with a font applied to it. **A director brief** frames the request in the context of the project before the tasks are drawn up. ### You approve the plan Read the plan. Approve it, edit it, or send it back with what it missed. Nothing is dispatched from a plan you have not approved — unless you have deliberately raised the autonomy level to skip that step, which is a decision you make once and can undo at any time. **Manual** — nothing runs until you press the button, including the planning. **Supervised** — planning starts on its own; work you have approved dispatches itself. **Autonomous** — healthy work ships without you, and review gates still stop for a human. **Approval is per request.** Trusting the pipeline for copy changes does not mean trusting it for a schema migration. ### It builds each task in isolation Each task is dispatched to the specialist that owns it and runs on its own branch, in its own git worktree, from a base branch you control. Tasks with no dependency between them run at the same time. A task that depends on another simply waits, and you can see it waiting. **No shared working directory.** One agent cannot read another's half-finished edit, because it is not there to read. **Abandoning is free.** A task you kill is a branch you delete. There is nothing to unpick from your default branch. **Watch it live.** Run streaming shows the commands Capy runs and the output it gets back, as it happens. **It asks rather than assumes.** A specialist that hits real ambiguity pauses mid-run and puts the question to you. **Front-end work gets a preview link** you can share with whoever needs to look at it before it merges. ### Gates, then merge Every task ends in a structured report: summary, files modified, risks, assumptions, recommendations and blockers. Governance roles read the work rather than produce it — the architect on shape, the code reviewer on the diff, the security engineer on exposure, QA on whether it does what the request asked for. Any role can be flagged `requires_review`, and when it is, dependent work stops until a human approves. **Governance roles can reject.** A reviewer that can only approve is decoration. **Blockers surface early**, in the report, rather than as a surprise in the merge. **Review gates hold at every autonomy level.** Autonomous does not mean unattended where you said it must not be. **Branches merge into your base branch** only once the gates you configured have passed. ### Deploy, check, and roll back if needed A deployment target is an SSH host with a deploy path, a deploy command, a health check, a diagnostics command and a rollback command. You write all five. A deployment run merges the work, runs your deploy command, then runs your health check. If the check fails, your rollback command restores the last commit known to be healthy — without waiting for anyone to wake up. **Phased and legible.** Merge summary, deploy output and health-check output are kept with the run, so a post-mortem has something to read. **Automatic rollback** is not a checkbox. It is your command, executed the moment the health check comes back unhealthy. **Your infrastructure.** We deploy into your servers and your repositories. There is no copy of your product living in ours. **A failed run opens an investigation** rather than a notification you have to act on yourself. ## When it goes wrong The stage everybody else stops before Shipping is not the end of the story. A deployment run that fails opens an **investigation**, with an agent already assigned to it and read-only access by default. ### Investigation Someone is already looking at it The rollback has run. The investigation opens against the failed deployment run, and an agent starts reading — logs, your diagnostics command, the diff that went out, the health-check output that refused to go green. #### Read-only by default an investigating agent looks. It cannot change your server unless you raise its access level deliberately. #### Access you can raise grant write access when you want it to act, and only then. The access level is recorded with the investigation. #### It ends in a summary a written cause and resolution you can read, forward, or paste into a status update. ### The loop closes The fix becomes the next request An investigation that finds a cause can open a follow-up request itself, linked back to the run it came from. The fix re-enters the same pipeline as everything else: planned, approved, built on a branch, reviewed, deployed and checked. #### Linked, not orphaned the new request carries the investigation it came from, so the history reads in order months later. #### No special path an emergency fix goes through the same gates. That is precisely when gates earn their keep. #### You still decide the follow-up request is a proposal on your board, not something already shipping while you sleep. ## Your side of the line What you control An organisation you cannot configure is one you cannot trust. Every setting below is yours, and every one of them is reversible. ### The team on the project Add the specialists this project needs. Leave out the ones it doesn't. Work planned for a missing role is reassigned and the substitution is recorded. ### Every role's contract Each role's behaviour is a Markdown document you can read and edit. Tighten it, loosen it, or write the standards your codebase actually holds. ### Which roles stop the line Flag any role as requiring review. Dependent work then waits for a human at every autonomy level, without exception. ### The autonomy level Manual, Supervised or Autonomous, per project. Start low. Raise it when the plans stop surprising you. ### The deployment target SSH host, deploy path, deploy command, health check, diagnostics command, rollback command. You write them; Capybari runs them. ### Model and effort Override the model and the effort level per project, or for a single request that deserves more thought than the rest. ### Investigation access Read-only unless you say otherwise. Raising an investigation to write access is a deliberate act, not a default. ### The base branch Tasks branch from the base you nominate and merge back into it. Your branching model stays your branching model. ## Autonomy How much of the pipeline runs without you Three levels, set per project. The gates do not move as you climb — only the number of buttons you press. Every level is on every plan, including the free one — how much runs without you is your decision to make, not something to buy. What a paid plan adds is reach: approved work deploying on its own, requests building on each other, and Capy starting work that should already have started. [See pricing](https://capybari.com/pricing/). What each autonomy level does automatically Planning a filed request | You start it | Starts on its own | Starts on its own Approving the plan | You approve every plan | You approve every plan | Healthy plans proceed Dispatching tasks | One press per task | Approved work dispatches itself | Dispatches as dependencies clear Roles flagged for review | Stops for you | Stops for you | Stops for you A specialist's question mid-run | Reaches you | Reaches you | Reaches you Isolated branch and worktree per task Health check before a deploy is called good Automatic rollback on a failed check Manual Supervised Autonomous ## Where the work happens In your repositories. On your servers. ### Repositories Connect the repos you already have A project holds one or more connected git repositories and the team that works on them. Capybari commits to branches in your repository — not to a fork, a mirror, or a copy that becomes the real one. #### Existing codebases welcome the boring middle of a product's life is the case we built for, not greenfield demos. #### One history, one convention one branch per task and one report per branch keeps a log somebody can still read next year. #### Leaving is a git operation your code is already where it lives. There is nothing to extract. ### Previews Look at it before it merges Front-end tasks generate a design preview with a shareable link, so the person with opinions about the button can have them at the point where changing it is cheap. #### Shareable send the link to someone who has never seen the board and does not want to. #### Before the gate, not after feedback arrives while the work is still on its own branch. #### Live output too run streaming shows the commands and results behind the preview if you want the detail. ## Boundaries What will not happen ### No merge past a gate you set. A role flagged as requiring review stops dependent work until a human approves it, at every autonomy level, with no override for urgency. ### No server we were not given. Capybari reaches exactly the deployment targets you define, using the commands you wrote. There is no discovery step and no agent installed on your host. ### No write access by assumption. Investigations open read-only. Raising one to write access is something you do on purpose, and the level is recorded on the investigation. ### No guessing in the dark. A specialist facing genuine ambiguity pauses and asks you a question. That pause is deliberate — it is cheaper than the alternative. ## Detail Questions about the pipeline Something specific to your setup? [Ask us](https://capybari.com/contact/) — a person replies. ### How long does a request take to plan? Planning is one agent run. Under the Project Manager hat, Capy reads the request and the connected repositories, then writes the plan summary, the tasks, the owners and the dependency graph. It lands on the board for you to approve, edit or reject. Nothing has been built at that point, which is what makes disagreeing cheap. ### Can two tasks change the same file at once? Each task has its own branch in its own git worktree, so no task can see another's uncommitted work. Where the ordering genuinely matters, the Project Manager records it as a dependency and the later task waits until the earlier one is done. ### What exactly does Capybari need on my server? SSH access, a deploy path, a deploy command, a health check, a diagnostics command and a rollback command. You write all of them, which means they run the way your infrastructure already expects. You can also run Capybari with no deployment target at all and merge by hand. ### What happens if the health check fails? Your rollback command runs and restores the last commit known to be healthy. The deployment run keeps its phases, merge summary, deploy output and health-check output, and an investigation opens against it with an agent assigned. ### Can I stop a run half way through? Yes. Work in progress lives on its own branch in its own worktree, so stopping is a local decision — nothing has touched your base branch. Live run streaming means you can see what you are stopping before you stop it. ### What if a role I need isn't on the team? Capability substitution reassigns the work to a role that can cover it, and records the substitution rather than performing it quietly. If nobody can cover it, the work stops and asks you. ### Does the pipeline change for an urgent fix? No, and that is deliberate. A fix from an investigation is planned, built on a branch, reviewed and health-checked like everything else. Skipping gates is how the second outage happens. ### Where do I see all of this? On the board. Requests, planned tasks, dependencies, running work, review gates, deployment runs and open investigations are one view. [The features page](https://capybari.com/features/) lists what each part shows you. ## Put one request through it Connect a 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 · Your repositories, your servers · Export everything, any time --- # Press URL: https://capybari.com/press/ Boilerplate you can copy, rules for using the Capybari name and mark, downloadable assets, key company facts and a press contact that answers within one working day. ## Press Everything a journalist needs, on one page. Copy the boilerplate, take the assets, check the facts. If you need something that is not here — a quote, a screenshot at a specific size, a walkthrough of the product — write to us and a person answers. First reply within one working day Assets free to use in coverage Facts checked against the product ## Boilerplate About Capybari — copy and paste Use either version verbatim. Both are approved, and neither needs to be cleared with us before publication. ## Short version — 41 words > Capybari is a fully managed AI engineering organisation for small and mid-sized > teams. You file a request; Capy plans it, builds each task on > isolated branches, review gates sign it off, and it deploys to your own servers > with health checks and automatic rollback. ## Long version — 122 words > Capybari is a fully managed AI engineering organisation. Rather than generating > code for a developer to shepherd, it runs the whole pipeline around the code. > A Project Manager agent turns a plain-English request into a task plan with > owners and dependencies. Fourteen specialist roles — from Architect to QA > Engineer to iOS Developer — pick up those tasks, each running on its own branch > in its own git worktree. Work done under the QA and Security hats can reject > work, not merely produce it. A DevOps Engineer deploys to a customer's own SSH > host, runs their health check, and runs their rollback command if it fails. > When production misbehaves, an investigation opens with read-only access, > writes up the cause and files the follow-up request. Founded 2025. ## One-line descriptor > Capybari — a fully managed AI engineering organisation. Ship calmly. ## How to describe the category We are not an AI coding assistant, an autocomplete or an IDE plugin. If you need a category label, **managed AI engineering** is the one we use: the customer does not hire the team, run the pipeline or carry the pager. ## What we ask you not to write - Do not describe Capybari as holding SOC 2, ISO 27001, HIPAA or PCI-DSS certification, or as offering a contractual uptime SLA, SSO/SAML, SCIM or an on-prem runner. We hold none of these today, and some are only on the roadmap. - Do not attribute customer counts, revenue, headcount, funding or "hours saved" figures to us. We do not publish them, and any number you have seen elsewhere did not come from us. ## Using the name and the mark Ten rules, all of them small None of this is legal throat-clearing. It exists so that our name looks the same everywhere it appears. **Do write Capybari** — one word, capital C, lower case for the rest. Not CapyBari, not capyBari, not CAPYBARI outside a setting where everything is capitalised. **Do call the animal a capybara.** The product is Capybari; the animal is a capybara; the mascot is "the Capybari capybara" and has no first name. **Do use the mark at 16px or larger.** Below that it stops being an animal and starts being a smudge. **Do leave clear space** around the mark equal to the height of the letter C in the wordmark. **Do use the single-colour version** on photographs, busy backgrounds or anything printed in one ink. **Don't recolour the mark.** Use the supplied light, dark or single-colour files as they are. **Don't stretch, squash, rotate, shear or outline it.** Scale it proportionally and leave it upright. **Don't add effects** — no drop shadows, gradients, glows, strokes or bevels over the supplied artwork. **Don't rebuild the wordmark** in another typeface, and do not set the name in all caps as a substitute for the logo file. **Don't imply endorsement.** Using our mark in editorial coverage is fine; using it on your product, event or landing page to suggest a partnership needs written permission first. ## Assets What you can use Everything below exists and is linked directly — no form, no email, no waiting. Assets are free to use in editorial coverage of Capybari without asking us first. If you need something that is not here, [write to press@capybari.com](mailto:press@capybari.com) and a person will answer rather than send you a portal. ### The mark, in vector The capybara mark as SVG — scales to any size, prints cleanly, and is the file to use whenever you can. [favicon.svg](https://capybari.com/static/img/favicon.svg) ### The mark, in raster 512px PNG on a transparent background, for anywhere SVG will not go. [logo-512.png](https://capybari.com/static/img/logo-512.png) ### App icons The square icon at 180, 192 and 512px, as shipped to browsers and home screens. [180](https://capybari.com/static/img/app-icon-180.png) · [192](https://capybari.com/static/img/app-icon-192.png) · [512](https://capybari.com/static/img/app-icon-512.png) ### The colours Reed green is the brand: **#0b8168** is the accent, running from **#eafbf5** at the lightest to **#04261f** at the darkest, with a warm clay used sparingly and never for links. ### The names **Capybari** is the product, one word, capital C. **Capy** is what the agent organisation is called inside it and is fine in prose. **Dackapps LLC** is the company. Never *Capybara*, *CapyBari* or *Capibari*. ### How the mark is built Construction, clear space, minimum size, the monochrome variants and what not to do with it are specified in full. Ask press@ for the specification if you need it before we publish it. ## Key facts Checkable details If a fact you need is not here, it is because we cannot yet stand behind it. Ask and we will tell you why. ### Product name Capybari. One word, capital C. The agent organisation inside the product is called Capy, which is fine to use in prose. ### Legal entity Dackapps LLC, registered in Delaware, United States. Company number 2505215. The company and the product have different names on purpose; Capybari is the product Dackapps builds. ### Founded October 2023. ### Founder Justin Green, Founder and CTO. [LinkedIn](https://www.linkedin.com/in/justin-green-591569342/). ### Registered office 16192 Coastal Highway, Lewes, Delaware 19958, United States — the registered agent's address, which is where legal notice is served. There is no head office: the team is remote and works to New York hours. ### What the product is A fully managed AI engineering organisation, run by a single agent called Capy. A request is planned into tasks with owners and dependencies, built on isolated branches, checked against what was asked, and deployed to the customer's own SSH hosts with health checks and automatic rollback; investigations open when production misbehaves. What changes between those stages is which of fourteen hats Capy is working under, not which agent has the task. ### Category Managed AI engineering. Adjacent to, and deliberately distinct from, AI coding assistants and autocomplete tools. ### Who it is for Technical founders and lead engineers at companies of roughly two to thirty people, non-technical operators running a product without an engineering team, and agencies running several client projects at once. ### How many agents One, called Capy. Reports describing Capybari as a team of agents are wrong, and it is the mistake most worth avoiding: there is a single agent that applies whichever expertise the work needs. ### The fourteen hats Capy Executive Assistant, Capy Full Execution, Product Owner, Project Manager, Architect, Developer, QA Engineer, Security Engineer, DevOps Engineer, UI/UX Designer, iOS Developer, Android Developer, Marketing Manager, Product Marketing Manager. Each is an editable Markdown contract naming the skills applied — not a separate agent. ### Autonomy levels Three: Manual, Supervised, Autonomous. Review gates and genuine escalations reach a human at every level. ### Pricing One paid plan, priced per project: $50 a month for the first and $40 for each after, with annual billing at ten months for twelve. Reading a codebase and producing its map is free. Viewers and collaborators are free, and the AI work runs on the customer's own subscription at no mark-up. ### Compliance We hold no compliance certification today and say so in public. SOC 2 Type II sits under "Later" on the [roadmap](https://capybari.com/roadmap/). Any report describing us as certified is wrong. ### Headcount, funding and customers Not published. We have no announcement to make about any of the three, and we would rather leave a gap than fill it. ## Announcements What we have announced, in order Product announcements only. We have made no funding, acquisition or partnership announcements, and this list would say so if we had. ### Company founded #### Capybari begins as an internal tool Dackapps LLC founded, to run the engineering work its founder could not staff. ### First agent organisation #### Fourteen specialist roles with editable contracts Coordinator, Governance and Worker roles, each defined by a Markdown document the customer can edit. #### Isolated worktrees and task dependency graphs Every task runs on its own branch in its own git worktree; dependent tasks wait, visibly, on the board. #### Review gates and three autonomy levels Manual, Supervised and Autonomous, plus a per-role human review flag that stops dependent work at any level. ### Deployment #### Deployment targets with health checks and automatic rollback Customers connect their own SSH hosts and supply the deploy, health-check, diagnostics and rollback commands. #### Live run streaming and design previews Runs stream commands and output as they happen; front-end tasks produce a shareable preview link. ### Investigations #### Production investigations ship A failed deploy opens an investigation with read-only access by default. It produces a summary and can open a follow-up request containing the fix. #### The free assessment opens Capy reads a customer's repositories and writes back a plain-English description of the system, with no card. Reading is free; changing is paid. ## Contact Talking to us ### Press enquiries [press@capybari.com](mailto:press@capybari.com). **We reply within one working day**, including to say that we have nothing to add. Tell us your deadline in the first line and we will work to it. ### What we will do Provide a named spokesperson for interview, check a technical claim in your draft, produce a screenshot at the size you need, and correct anything on this page that is out of date. Fact-checking a draft is not conditional on editorial approval — send us the sentences, keep the article. ### What we will not do Confirm a compliance certification we do not hold, supply a customer number or growth figure we do not publish, or put a customer in front of you without their own written agreement first. ### Security researchers Not a press matter — please use [security@capybari.com](mailto:security@capybari.com) and the process on our [security page](https://capybari.com/security/). ## Want to see it running? We will walk you through a request going from a sentence to a deployed change, including the part where the health check fails and it puts everything back. Assets free to use in coverage · First reply within one working day --- # Pricing URL: https://capybari.com/pricing/ One plan, priced per project. $50 a month for the first, $40 for each after. Reading your code is free; changing it is what you pay for. ## Pricing $50 per project. Per month. Then $40 a month for every project after the first. One plan, no seats, no tiers to compare.\n\n**Reading your code is free.** Changing it is what you pay for. Annual: ten months for twelve Viewers and collaborators are free The AI work runs on your own subscription ## What one licence covers A project, and the capacity to work on it These are the four things the platform measures. A project inside all four is one licence, whatever it is written in and however many files it has — file count is not the cost, size is. Everything else is uncapped: requests, agent runs, team members, history, investigations. There is no monthly allowance to use up. Your code | 2 GB | The working tree — not git history. Check it yourself with `du -sh --exclude=.git`. Repositories | 5 | A front end, an API, infrastructure, and room for two more. Tasks at once | 3 | What your work occupies on our machines while it runs. Deployment targets | 2 | Staging and production, or two environments of your choosing. Per licence Why this is the number ## Projects bigger than one licence A large project uses as many licences as it needs Rather than a separate enterprise tier with a conversation attached, a heavy project simply consumes more of the same unit — and every axis scales with it. ### Worked example A 6 GB monorepo is three licences $50 for the first, $40 and $40 for the next two — **$130 a month**. With it comes 15 repositories, 9 tasks at once and 6 deployment targets, because the capacity multiplies too.\n\nMost projects are one licence. This is what happens when yours is not, and it is arithmetic rather than a sales call. ### If you outgrow it mid-month Nothing is cut off Work already running finishes — a build mid-flight, a deploy mid-flight, an investigation mid-flight. What pauses is new work, until you add the capacity.\n\nWe are not going to stop your deploy over a gigabyte. ## Free, and not a trial Reading is free. Changing is paid. Point Capy at your repositories and it reads the project and writes back what it found: what the system is, what it is built from, how the parts relate, and where the sharp edges are. ### What free covers The assessment, on our account That read costs real money in AI work and **we pay for it**, on our own keys, before you have paid us anything. No card, no countdown, and the document is yours whatever you decide next. ### Where paid starts The first change The moment you want something built, tested, reviewed and shipped, that project needs a licence. It is a clean line: you know exactly what you are buying, and you have already seen what Capy makes of your code before you buy it. ## The AI work Your subscription, at no mark-up Connect your own Claude or Codex subscription, or an API key, and the work runs on it. We add nothing to it.\n\nThat is deliberate, and it is why the price above is a flat figure. If compute were folded in, a month where you shipped a lot would arrive as a bigger invoice — a price rise for doing more of exactly what you bought the thing for. **Capacity is ours to price; consumption is yours to control.**\n\nIf you would rather not manage a provider account, you can buy credits and spend from those instead. ## The questions this raises What $50 is actually paying for Something not answered here? [Ask us](https://capybari.com/contact/) — a person replies. ### If I bring my own AI subscription, what am I paying you for? The standing capability around the work. We pay for the assessment that reads your codebase, on our own account, before you pay us anything. Your project then occupies disk continuously — the repository plus an isolated copy per task in flight — and its runs, tests and builds execute on our machines. And it is watched: health checks, automatic rollback and an investigation that opens itself happen whether or not you filed a request this month. ### Why is a dormant project still charged? Because dormant is not idle. The understanding of the codebase is kept current, the deployment is still watched, and the capacity is still held. A project you did not touch this month is one you can touch tomorrow without a fortnight of re-learning first. ### Why measure storage rather than files or lines? Because size is what costs us and file count is not. Ten thousand files of Python is a small project; ten thousand images is not. Storage tracks how heavy a project actually is to hold and to work in. ### Does my git history count toward the 2 GB? No. The measurement is your working tree — the code as it stands — and you can check it yourself with `du -sh --exclude=.git`. We keep the full history because the agents need it, and we absorb that cost. A repository with a decade of commits can be more than twice its working tree, and charging you a second licence for 2019 would be indefensible. ### What happens if my repository grows past 2 GB? Work already running finishes. New work waits until you add capacity, which is one more licence at $40. Nothing is deleted and nothing is cut off mid-flight. ### Is there a discount for many projects? Yes — the first project is $50 a month and every project after it is $40. Fifteen projects is $610 a month rather than $750. Annual billing is ten months for twelve on top of that. ### Do you charge per user? No. Viewers and collaborators are free, however many of them there are. Put your whole team and your client in to watch; it changes nothing about the price. ### What is not included? We hold no SOC 2 and offer no contractual uptime SLA today, and say so on [the security page](https://capybari.com/security/) rather than in a footnote. If you need either contractually, we are not your platform yet. ## Find out what you own before you pay for anything Point Capy at a repository and read what comes back. The assessment is free, on our account, and commits you to nothing. Free · no card · $50 a month when you want the first change made --- # Privacy Policy URL: https://capybari.com/privacy/ What personal data Capybari collects, the lawful bases we rely on, our sub-processors, retention periods and how to exercise your rights under the UK GDPR and GDPR. ### Written to be read, not to be survived. Every sub-processor is named, every retention period is a real number, and where we have not done something — an Article 27 representative, a Data Protection Officer — this page says so instead of going quiet. If a question you have is not answered here, [privacy@capybari.com](mailto:privacy@capybari.com) reaches a person. ## Privacy Policy ## 1. Who we are Capybari is a managed AI engineering platform. This policy explains what personal data we collect when you visit this website, create an account, or use the platform, and what we do with it. For the purposes of the UK GDPR and the EU GDPR: - We are the **controller** of personal data about our website visitors, account holders and billing contacts. - We are a **processor** acting on your instructions for personal data that happens to be contained in the code, repositories, logs and systems you connect to the platform. Your contract with us, and any data processing agreement attached to it, governs that processing. In short: we are the controller of data about *you as an account holder*, and the processor of whatever personal data happens to live inside the systems you connect. **Dackapps LLC**, the company behind Capybari Registered office: 16192 Coastal Highway, Lewes, Delaware 19958, United States Company number: 2505215 Country of registration: United States We have not appointed a Data Protection Officer, and we are not required to: we are not a public authority, and our core activities are neither large-scale monitoring nor large-scale processing of special category data. Privacy questions go to **privacy@capybari.com** and reach a person who can act on them. If one is appointed, or if the appointment is legally required, their name and contact details go here. Our position on an Article 27 representative is in section 8. ## 2. How to contact us Write to **privacy@capybari.com** for anything in this policy, including requests to exercise your rights. For security matters, including reporting a vulnerability, write to **security@capybari.com**. For anything else, **hello@capybari.com**. Postal correspondence goes to the registered office above. ## 3. What we collect ### 3.1 Account data Your name, work email address, password hash, organisation name, the role you hold in that organisation, your account settings, and the timestamps of your sign-ins. If you sign up through a git host, we receive the account identifier and email address that host gives us. ### 3.2 Project and repository metadata The names, URLs and default branches of the git repositories you connect, the credentials or tokens you supply to reach them, the projects and teams you configure, and the requests and tasks on your board. Commit metadata such as author names and email addresses is present in the repositories you connect and is processed as part of running the service. ### 3.3 Agent run logs and reports The prompts, commands, command output, diffs, structured completion reports, investigation summaries and streamed run events produced when work runs on your projects. These may contain personal data if your repositories, logs or diagnostics contain personal data. They are stored so you can read the record of what happened, and so we can debug failures you report. ### 3.4 Deployment target configuration The SSH hostnames, usernames, deploy paths, deploy commands, health checks, diagnostics commands and rollback commands you define, along with the credentials needed to reach those hosts, and the phase-by-phase output of each deployment run. ### 3.5 Billing data Your billing name, billing email, billing address, VAT or tax identifier, plan, agent-run counts used for metering, invoices and payment status. **Card numbers are handled by our payment processor and are never stored on our systems.** ### 3.6 Support and correspondence Messages you send us by email or through a form on this site, and our replies. ### 3.7 Campaign attribution If you reach this site through a tagged campaign link — an advertisement, a newsletter, a partner's post — we keep the campaign labels from that link and send them with any form you then submit, so we can tell which campaign produced which enquiry. We keep both the first campaign that brought you here and the most recent one before you got in touch. These are labels we wrote into our own links; they contain no identifier and no record of what you read. See the [cookie policy](https://capybari.com/cookies/) for where they are stored in your browser. ### 3.8 Website analytics We keep server-side request logs for this marketing website — the requested URL, timestamp, response status, referrer, user agent and a truncated IP address — for security and capacity purposes. **We run no advertising trackers on this marketing website.** There is no advertising network, no session recorder, no social pixel and no third-party font or script. There is **one** analytics tag: Google Analytics 4, which currently runs on every visit while the site is new. The [Cookie Policy](https://capybari.com/cookies/) says so plainly, names the cookies it sets, and explains how to stop it. Google acts as our processor; we have turned off Google Signals and ad personalisation, so nothing here feeds an advertising profile. ### 3.9 What we do not ask for We do not ask for special category data — health, biometrics, race, religion, political opinions, trade union membership, sex life or sexual orientation — and the platform is not designed to process it. Do not connect systems containing special category data without a written agreement with us first. ## 4. Lawful bases | What we process | Lawful basis | | --- | --- | | Account data, project metadata, run logs, deployment configuration | Performance of a contract (Article 6(1)(b)) — we cannot run the service without them | | Billing and payment data | Performance of a contract, and legal obligation (Article 6(1)(c)) for tax and accounting records | | Campaign labels submitted with a form | Legitimate interests (Article 6(1)(f)) — knowing which campaign produced an enquiry we were going to answer anyway | | Security logging, fraud prevention, abuse investigation | Legitimate interests (Article 6(1)(f)) — keeping the platform and our customers safe | | Service email about outages, security and material changes | Legitimate interests, and performance of a contract | | Marketing email to people who asked for it | Consent (Article 6(1)(a)), withdrawable at any time | | Personal data inside your repositories, logs and connected systems | We process it on your documented instructions as a processor; you determine the lawful basis | Where we rely on legitimate interests, we have considered whether our interest is overridden by your rights. You can object to that processing at any time — see section 10. ## 5. How we use it - To run the platform: plan requests, execute tasks in isolated worktrees, run review gates, deploy to the targets you configure, and open investigations when something fails. - To authenticate you and keep your account secure. - To count agent runs, apply your plan's limits, and settle credit balances. - To answer support requests and debug faults you report to us. - To detect, investigate and stop abuse, fraud and attacks on the platform. - To send service messages about incidents, security and material changes to this policy or our terms. - To meet our legal, tax and accounting obligations. - To improve the platform's reliability, using aggregate operational metrics such as error rates, run durations and queue depth. We do not sell personal data. We do not share it with advertisers. We do not use it for automated decision-making that produces legal effects for you. ## 6. We do not train models on your data **We do not use your code, your prompts, your agent run logs, your completion reports or your deployment output to train, fine-tune or otherwise improve any machine learning model — ours or anyone else's.** Your content is sent to third-party model providers only to produce the output of a run you asked for. We configure those providers so that content sent through our accounts is excluded from their model training, and we require that exclusion contractually, and the agreements with **Anthropic**, **OpenAI** and **OpenRouter** forbid it. You can also connect your own provider account on any plan, which takes us out of that relationship entirely. See the named provider before launch, and record the zero-retention or limited-retention setting that applies to each. Where a model provider retains prompt and output data briefly for abuse monitoring, that retention is set by the provider. We name the providers and their retention behaviour in section 7 once they are confirmed. ## 7. Sub-processors We use a small number of third parties to run the service. Each is bound by a written contract that limits them to processing on our instructions and requires appropriate security measures. This list is dated and we give notice before adding to it. Processing locations are named because "the cloud" is not an answer to where your code is executed. | Category | Purpose | Vendor | | --- | --- | --- | | Cloud hosting and infrastructure | Running the application, databases, backups and agent execution environments | **Contabo** (Europe and United States) and **Vultr** (Europe and United States) | | Model providers | Producing the output of agent runs | **Anthropic**, **OpenAI** and **OpenRouter**. Not used where you connect your own provider account | | Payment processing | Taking payment and issuing receipts | **PayPal**. Card details are handled by PayPal and never reach our systems | | Email delivery | Sending account, service and support email | None — we run our own mail server. Your address is not shared with a delivery vendor | | Error and uptime monitoring | Detecting faults and outages | None. We have no third-party monitoring vendor; see the [status page](https://capybari.com/status/) for what that means in practice | ## 8. International transfers Some of these sub-processors are located outside the United Kingdom and the European Economic Area. Where personal data is transferred outside the UK or the EEA, we rely on one of the following: - An adequacy decision by the UK government or the European Commission covering the destination country. - The UK International Data Transfer Agreement, or the UK Addendum to the EU Standard Contractual Clauses. - The EU Standard Contractual Clauses, with a transfer risk assessment on file. We are a United States company, so personal data reaching us is transferred out of the UK and the EEA by definition. That transfer relies on the **Standard Contractual Clauses**, together with the UK Addendum for UK data, and the same mechanism covers our US-located hosting. Hosting in Europe stays in Europe. You may request a copy of the relevant safeguards by writing to privacy@capybari.com. **We have not yet appointed an EU or UK representative under Article 27**; if you are in the EU or UK and would ordinarily contact one, write to privacy@capybari.com and we will answer directly. ## 9. Retention We keep personal data only as long as we need it. The periods below are the ones we operate to. | Data | Retention | | --- | --- | | Account data | For the life of the account, then deleted within 30 days of closure | | Project, repository and board metadata | For the life of the account, then deleted within 30 days of closure | | Agent run logs, streamed events and completion reports | 12 months from the run, or until you delete the project, whichever is sooner | | Deployment target configuration and credentials | Until you delete the target; credentials are deleted immediately on deletion | | Deployment run output and health-check output | 12 months | | Investigation records | 12 months | | Billing records and invoices | 7 years, to meet UK tax and accounting requirements | | Support correspondence | 24 months from the last message | | Website server logs | 90 days | | Security and audit logs | 12 months | | Backups | Rolling backups are overwritten within 35 days; deleted data persists in backups until that cycle completes | When a retention period ends we delete the data or irreversibly anonymise it. ## 10. Your rights Under the UK GDPR and the GDPR you have the right to: - **Access** — get a copy of the personal data we hold about you. - **Rectification** — have inaccurate data corrected and incomplete data completed. - **Erasure** — have your data deleted where we no longer have a lawful reason to keep it. - **Portability** — receive the data you gave us in a structured, commonly used, machine-readable format, and have it transmitted to another controller where technically feasible. - **Object** — object to processing we carry out on the basis of legitimate interests, and to direct marketing at any time and without reason. - **Restriction** — ask us to pause processing while a dispute about accuracy or lawfulness is resolved. - **Withdraw consent** — where we rely on consent, withdraw it at any time. Withdrawal does not affect processing carried out before you withdrew. ### How to exercise them Write to **privacy@capybari.com** with the request and enough information for us to find your records. We will respond within **one month**. If the request is complex we may extend that by a further two months and will tell you why within the first month. We do not charge a fee unless a request is manifestly unfounded or excessive, in which case we will tell you the charge before doing the work. We may ask you to verify your identity before we act. If your personal data sits inside a customer's repository, logs or connected systems, that customer is the controller. Send your request to them; we will support them in answering it, and we will pass on requests that reach us in error. ## 11. Cookies This marketing website sets no advertising or third-party cookies and loads no third-party scripts. The signed-in application uses a small number of strictly necessary cookies. The [Cookie Policy](https://capybari.com/cookies/) lists every item by name, purpose and duration. ## 12. Children The platform is not intended for children. We do not knowingly collect personal data from anyone under 16. If you believe a child has given us personal data, write to privacy@capybari.com and we will delete it. ## 13. Changes to this policy We may update this policy. When we do, we change the "last updated" date at the top and keep the previous version on file. If a change materially affects how we handle your personal data, we will email account holders at least **30 days** before it takes effect. ## 14. Complaints If you are unhappy with how we have handled your personal data, tell us first at privacy@capybari.com so we can try to put it right. You also have the right to complain to a supervisory authority. We are a United States company, so we do not have a lead authority of our own — you complain to the one where you are. If you are in the **United Kingdom**, that is the Information Commissioner's Office: **Information Commissioner's Office** Wycliffe House, Water Lane, Wilmslow, Cheshire, SK9 5AF, United Kingdom Telephone: 0303 123 1113 Website: [ico.org.uk](https://ico.org.uk/make-a-complaint/) If you are in the EEA, you may complain to the supervisory authority in your country of residence, place of work, or the place where the alleged infringement happened. Last updated 5 September 2026 --- # Resource library URL: https://capybari.com/resources/ Guides for getting a request to production, templates you can copy, honest comparisons against the alternatives, and recordings of how the platform actually behaves. ## Resources Everything we wrote down so you don't have to work it out Guides for the first fortnight, templates you can paste into your own board, comparisons we would rather you read before buying, and a walkthrough for the people who prefer watching. Free, no form in the way British English, plain words Updated when the product changes ## Guides Start here Five walkthroughs, in the order most teams need them. Each one ends with something working rather than something understood. ### Get your first request to production Connect a repository, file one request, approve the plan, watch the tasks run on their own branches, and merge. The whole loop, once, on something small. 20 min · Beginner ### Choose your autonomy level What Manual, Supervised and Autonomous each change, what stays gated at every level, and the questions to answer honestly before you move up one. 10 min · Beginner ### Write a request that plans cleanly Give the Project Manager an outcome, a constraint and a place to look. Includes worked examples of the same request written badly, then written well. 12 min · Beginner ### Configure a deployment target that can roll back Set up the SSH host, deploy path, deploy command, health check, diagnostics command and rollback command — then break it on purpose to prove the rollback runs. 25 min · Intermediate ### Assemble a project team Pick the specialists a project genuinely needs from the fourteen roles, decide which ones require human review, and see what capability substitution does with the gaps you leave. 15 min · Intermediate ## Templates Copy these rather than inventing them Plain Markdown. Paste them into a request, a role contract or your own runbook and edit until they sound like your team. ### Request templates for bugs, features and investigations One structure per request type: what is happening, what should happen, where to look, and what must not change. The investigation template includes the fields a follow-up request needs to be useful. 3 files · Markdown ### A role contract template The skeleton we use for our own roles: what this specialist owns, what it must escalate, where it must stop, and the shape of the report it hands back. 1 file · Markdown ### A deploy runbook template The commands, in order, with the failure branch written down beside each one. Fill it in before you connect the target, not after your first bad night. 1 file · Markdown ### A health check checklist Twelve questions that separate a check which proves your service works from one that proves your web server is answering the phone. 1 page · Markdown ## Teardowns & comparisons What we are, next to what you are already considering Written to be useful rather than flattering. Each one names the case where the other option is the better buy. ### Capybari next to an AI coding assistant An assistant speeds up the person in the chair. We are for the work that has to happen when nobody is in the chair: planning, review, deployment, the investigation afterwards. If you love your editor, keep it. 9 min read ### Capybari next to hiring a contractor Availability, context, review and what happens at 3am, compared honestly. A contractor who already knows your codebase is hard to beat; a contractor you have not hired yet is not. 11 min read ### What a managed engineering organisation costs against staffing one The roles a small team cannot justify hiring — QA, security, DevOps — priced against agent runs, with the method shown so you can put your own numbers in. 14 min read ## Watch If you would rather see it move ### The twelve-minute product walkthrough One request, filed and shipped, with nothing cut. The plan, the approval, four tasks on four branches, the review gate, the deploy, the health check. 12 min · No sign-up ### Office hours recordings Our engineers answer whatever turns up — usually autonomy, rollback and what to do with a plan you disagree with. Recorded and published afterwards. 45 min each · Monthly ## Which one Pick by how much time you have Four kinds of resource, four different jobs. Nothing here needs to be read in order. Looking for reference material rather than teaching material? That is [the documentation](https://capybari.com/docs/). Resource types compared by audience and time required Guides | Anyone in their first fortnight — technical or not | 10–25 minutes each | Something configured and working in your own project Templates | Whoever files the requests and edits the role contracts | 5 minutes to copy, ongoing to refine | A house style for requests, contracts and runbooks Teardowns & comparisons | The person deciding whether to buy | 9–14 minutes each | A straight answer, including where we are the wrong choice Watch | Teams who want to see it before reading about it | 12–45 minutes | A clear picture of what the board looks like under load Resource type Who it is for How long it takes What you end up with ## Elsewhere The rest of what we publish ### Documentation Reference for every part of the platform, from role contracts to deployment targets. Instructional, second person, no marketing. ### Help centre Answers to the questions support actually receives, plus how to reach a person when the answer is not there. ### Community Where teams compare role contracts, request patterns and health checks. We read it; we do not moderate it into silence. ### Changelog Dated, specific and honest about what is still missing. The [roadmap](https://capybari.com/roadmap/) covers what comes next. ## The digest Get told when a new resource lands One email a month: new guides and templates, plus a short note on what shipped. One click to stop. We store your address to send the digest and nothing else. [How we handle data](https://capybari.com/privacy/). ### email Email address ## The first guide works better with a project open Connect a repository, file the thing that has been on your list for a month, and read the plan. Manual autonomy — nothing runs without you. Free · no card · Capy reads your repositories and writes you a plain-English description of your own software --- # Roadmap URL: https://capybari.com/roadmap/ Read what has shipped, what we are building this quarter, and what is still only an idea. Quarterly honesty, no promises we cannot keep, and no dates we will hide. ## Roadmap What we are building. And what we are not. Our first value is showing the work, so the roadmap is public rather than something you extract from a sales call. Read it as a statement of intent — dated by quarter, ordered by conviction. **Nothing on this page is a contractual commitment.** Dates move, items get cut, and when they do we change the page rather than quietly delete the row. Updated every quarter Cut items stay visible No paid prioritisation ## The list Shipped, building, next, later, undecided Five buckets. The first one is the only one you can rely on today — everything under it is a plan, and plans are worth exactly what plans are usually worth. Anything that ships moves to the [changelog](https://capybari.com/changelog/) with the date it landed. Anything we cut stays on this page, marked as cut, until the next quarterly rewrite. ### Shipped #### Projects and the board Connect git repositories, choose the hats each project may use, and file requests that are typed, prioritised, reorderable and archivable. #### Project Manager planning A request becomes a plain-English plan and a task graph with owners and `depends_on` dependencies. You approve it, edit it, or send it back. #### Fourteen specialist roles Fourteen hats, from Product Owner to Android Developer, each an editable Markdown contract you can read and change. #### Isolated worktrees and branches Every task runs on its own branch in its own git worktree. Parallel work cannot collide, and an abandoned task is a deleted branch. #### Dependency graphs A task that depends on another waits for it. The graph is visible on the board rather than implied by task order. #### Review gates Flag any role as requiring human review and dependent work stops until a person approves it — at every autonomy level. #### Three autonomy levels Manual, Supervised and Autonomous. Start where nothing runs without you and move up when the plans stop surprising you. #### SSH deployment targets Define a host, a deploy path, a deploy command, a diagnostics command and a rollback command. Your server, your commands. #### Health checks A deployment run is not healthy until your health check says so. The output is kept with the run. #### Automatic rollback A failed health check restores the last commit known to be healthy, without waiting for anyone to wake up. #### Production investigations Failure opens an investigation. The agent reads logs and diagnostics at read-only access, writes a summary, and can open the follow-up request itself. #### Live run streaming Watch a task work as it happens — the commands it runs and the output it gets back, streamed rather than batched. #### Design previews Front-end tasks produce a shareable preview link, so people can look at the change before it merges. #### Role contract editor Tighten a role, loosen it, or write your own. Behaviour is a document, not a hidden prompt. ### Now #### GitHub and GitLab native app A first-class app rather than a git remote and a token. Richer checks, cleaner authorisation, fewer setup steps. #### Slack notifications Plans awaiting approval, review gates, failed health checks and opened investigations, delivered where your team already is. #### Cost controls per project Per-project budgets and clearer usage reporting, so a runaway project is visible before the invoice is. #### Investigation write-access hardening Tighter scoping and clearer audit around the moment an investigation is raised from read-only to write. ### Next #### SSO (SAML) Single sign-on through your identity provider. Not available today at any price — see the [pricing page](https://capybari.com/pricing/) for the full list of what we are missing. #### Audit log export Export the record of who approved what, when, and what changed as a result — to a file you keep. #### Scheduled and recurring requests Dependency upgrades, weekly housekeeping and the maintenance nobody remembers, filed on a schedule. #### Multi-region deployment targets Roll one deployment run across several hosts in order, with the health check gating each step. #### Public API v1 File requests, read runs and reports, and drive the board from your own systems. There is no public API today. ### Later #### SOC 2 Type II We hold no certification today and we will not imply one. When an audit is complete, the report will say so and this row will move. #### Custom role marketplace Share and install role contracts written by other teams, on the same editable Markdown the built-in roles use. #### On-prem runner Execute runs inside your own network. Today every run happens on our infrastructure against your repositories. #### Uptime SLA A contractual availability commitment with remedies attached. We do not offer one now. The [status page](https://capybari.com/status/) reports observed uptime and promises nothing. #### Enterprise tenancy Dedicated tenancy and the procurement motion that goes with it. Until then, the Enterprise tier is a waitlist and says so. ### Considering #### Mobile app Approve a plan and watch a deployment run from a phone. Useful, unproven, and easy to build badly. #### Jira and Linear two-way sync Mirror requests into the tracker your company already argues about. The hard part is deciding which side wins a conflict. #### Terraform provider Declare projects, teams and deployment targets as code. Waiting on the public API landing first. #### Self-serve model keys Rotating and replacing your own model keys from project settings, rather than asking us to change them for you. ## Influence How this list actually changes Roadmaps drift towards whoever shouts loudest. These are the three routes that reach us, in the order they carry weight. ### Describe the problem, not the feature. Post in the feature requests channel on [our community](https://capybari.com/community/) and tell us what you do today instead. "I export the audit trail by screenshotting the board every Friday" moves an item further than "please add reporting". ### Turn up to office hours. Monthly, an hour, with whoever is building the thing you care about. We take the roadmap questions live rather than deferring them to a form. Dates are on the [community page](https://capybari.com/community/). ### Tell us when something is worse than it looks. A rough edge you have worked around for three months outranks most new features. Send it to [support](https://capybari.com/contact/) with the run and we will treat it as roadmap input, not just a fix. ## How we decide The six questions every item has to survive We build for the stretched builder: the person who ships the product, runs the servers and carries the pager. These are the tests an idea has to pass before it gets a quarter. ### Does it make a gate stronger? Review, approval, health checks and rollback are the product. Work that hardens one of them starts ahead of work that adds a surface. ### Who asked, and how often? We count distinct teams, not messages. Four teams describing the same workflow independently beats forty upvotes on one thread. ### Does it fit the mechanism? Requests, tasks, runs, deployment targets, investigations. If a feature needs a new concept beside those, it usually needs a rethink. ### Can we support it at 3am? Anything that touches your production hosts has to be operable by a small team under pressure. If we cannot, we do not ship it. ### What does it widen? Every integration and every access grant enlarges the blast radius. The security engineer's view counts as a veto, not an opinion. ### Can we describe it honestly? If a feature only sounds good when described vaguely, it is not finished. Copy that survives the [security page](https://capybari.com/security/) is the bar. ## Questions The awkward ones about roadmaps Missing something you need? [Tell the community](https://capybari.com/community/) — we read every thread. ### Will you commit to a date? No. The quarters here are our current best estimate and they move. Nothing on this page forms part of a contract, an order form or a renewal, and no salesperson can convert it into one. If a purchase depends on a capability existing, buy the product as it is today and treat everything below **Shipped** as a bet you have not paid for. ### Can I pay to have something prioritised? No, on any plan. We do not sell roadmap position, and we would rather lose the deal than build a product shaped by whoever spent the most last quarter. Paying customers do get heard more clearly, because they use the thing every day and their descriptions are better. That is influence earned through use, not through invoice. ### What happens to items under Considering? They stay genuinely undecided. Some get scheduled, some get closed, and some sit there for a year while we wait for enough teams to want them. An item under Considering has no quarter attached because we have not decided to build it. When we do decide either way, we say so on this page rather than removing the row quietly. ### How do I request something? Post it in the feature requests channel on the [community page](https://capybari.com/community/), or write to us at [our contact form](https://capybari.com/contact/) if it is commercially sensitive. Useful requests describe a workflow: what you are trying to do, what you do instead today, and what it costs you. We will tell you which bucket it landed in, including when the answer is no. ### Something moved out of Now. Why did nobody say? We rewrite this page every quarter and note what slipped. If an item moved and you were waiting on it, that is a failure of communication on our side — tell us and we will write to the people affected the next time it happens. ### Is the roadmap the same as the changelog? No. The [changelog](https://capybari.com/changelog/) is what has already landed, with dates. This page is what has not. When something ships it moves from here to there, and the Shipped bucket above is a summary of the changelog rather than a second source of truth. ## Argue with this roadmap The list gets better when the people using the product push back on it. Join the community, post what you are stuck on, and turn up to office hours. Monthly office hours · Feature requests read weekly · No paid prioritisation --- # Security URL: https://capybari.com/security/ How Capybari contains agent work: an isolated worktree per task, review gates, read-only investigations and automatic rollback — plus the certifications we do not hold. ## Security Agents work inside boundaries you set This page describes the mechanisms, in the same words the product uses: isolated worktrees, review gates, read-only investigations, automatic rollback. It also lists, without hedging, the certifications we do not hold. Your repositories, your servers Read-only by default No training on your code ## Mechanisms What actually holds the line Eight things the platform does today. Each one is a control you can inspect, not a property we claim. ### An isolated worktree per task Every task runs on its own branch in its own git worktree. Parallel work cannot collide, and one agent cannot read another's half-finished changes. ### Review gates that stop work Flag any role as requiring review and dependent tasks stop until a human approves. This holds at every autonomy level, including Autonomous. ### Read-only investigations An investigation opens with read-only access. It reads logs and runs your diagnostics command. Write access is a separate grant a person makes. ### Automatic rollback A failed health check triggers the rollback command you wrote, returning the target to the last commit known to be healthy. ### Encrypted credential storage SSH keys and git tokens are stored encrypted and are never returned to the interface or printed into run output once saved. ### Per-project deployment targets A deployment target belongs to one project. A project cannot deploy to a target it does not own, so a client's server stays reachable only from that client's work. ### Ownership boundaries Projects, repositories, teams and targets belong to one account. Owner and admin roles decide who inside it can approve plans, grant access and connect servers. ### An audit trail by construction Every task ends in a structured report — summary, files modified, risks, assumptions, recommendations, blockers — beside the branch, the diff and the run log. ## In detail Three boundaries, drawn precisely Isolation, review and access. Everything else on this page follows from these three. ### Isolation Work happens on a branch, in a worktree, or it does not happen There is no path by which an agent edits your working copy. Each task is given a base branch, a new branch and a worktree of its own, and it can only write there. #### One task, one branch the branch name and the worktree path are recorded on the task, so you can check out exactly what an agent did. #### No shared scratch space two tasks running at once cannot see each other's files, which also removes a whole class of merge accidents. #### Abandonment is free an abandoned task is a deleted branch. Nothing has to be unpicked, because nothing was merged. #### Dependencies wait a task whose `depends_on` list is unfinished does not start, so partial work is never built on. ### Review A gate is a stop, not a notification Marking a role `requires_review` halts everything downstream of its work until a person approves. Autonomy level does not override it. #### Plans need approval first nothing is dispatched from a plan you have not approved, unless you deliberately set the project to skip that step. #### Governance roles can reject under the Architect, QA and Security hats Capy returns work rather than merely commenting on it — and the review that is genuinely independent is the gate you set. #### Agents ask when they are unsure a specialist that hits genuine ambiguity pauses and puts a question to you instead of guessing. #### Merges are visible you see the diff, the reviewer's verdict and the security note before anything reaches your default branch. ### Access Production access is granted, never assumed When a deployment fails its health check, an investigation opens automatically at the lowest access level and stays there unless a human raises it. #### Read-only is the default the agent reads logs and runs the diagnostics command you defined on the deployment target. That is the whole of its reach. #### Write access is explicit and per-investigation raising the level is a deliberate act by a person, recorded on the investigation, and it does not persist to the next one. #### The output is a summary, not a change an investigation ends by writing up what happened and, if you want it, opening a follow-up request containing the fix. #### The fix goes through the front door that follow-up request is planned, built, reviewed and deployed like any other. Incidents do not create a bypass. ## Data handling What we do with your code, stated plainly Commitments, not aspirations. If one of these stops being true, this page changes before the product does. **We do not train models on your code.** Not on your repositories, your requests, your plans, your reports or your run logs. **Repositories are cloned to run your work.** That is the reason we hold a copy, and it is the only reason. **Your code lives in your repositories.** Agents commit to branches in the remote you connected. We are not the system of record. **Deploys go to your servers.** A deployment target is your SSH host, running your deploy command against your infrastructure. **You own the credentials.** Revoke a git token or an SSH key on your side and our access ends immediately, with no request to us. **Export whenever you like.** Requests, plans, tasks and reports come out in a machine-readable form, before or after you cancel. **Working copies are disposable.** A task's worktree exists for the run and the branch that came out of it, not indefinitely. **Deletion means deletion.** Cancel and we keep the account readable for 30 days, then remove it and its clones. **Model providers process, they do not keep.** Work is sent to model providers under agreements that forbid training on it, and Business customers can supply their own keys instead. **Support does not browse.** Our staff do not read your repositories to answer a support question; access for debugging is requested from you and time-boxed. ## Access model Who and what can reach your systems Four kinds of person, three kinds of agent access. Nothing else has a route in. ### Owner Holds the account. Connects repositories, adds deployment targets, sets the autonomy level, manages billing and can delete the account. There is always at least one. ### Admin Runs the day-to-day organisation. Adds and removes people, builds project teams, edits role contracts and approves plans. Cannot delete the account. ### Member Files requests, approves plans and review gates on projects they are on, dispatches work and answers an agent's questions. Counts as a seat. ### Viewer Reads the board, plans, diffs, reports and design previews. Cannot dispatch a run, approve a gate or touch a deployment target. Free, on every plan. ### Agent — repository access Scoped to the repositories connected to the project the task belongs to, and confined to that task's own branch and worktree. It cannot write to your default branch; a merge is a separate, gated step. ### Agent — deployment access Only exists where you defined a deployment target. The agent runs the deploy, health check, diagnostics and rollback commands **you wrote**, over SSH, on that host and no other. ### Agent — investigation access Opens at `read_only`: logs and diagnostics, nothing more. Raising it to write is an explicit human decision, recorded on the investigation and limited to it. ### Capability substitution When a project team lacks the role a task needs, the work is reassigned to a role that can cover it — and the substitution is written onto the task. Silent reassignment would be an access change you could not see. ## Responsible disclosure Reporting a vulnerability We would rather hear it from you than from an attacker. This is our whole process; there is no separate portal and no intermediary. ### How to report Email **security@capybari.com**. Include: - what you found, and the URL, endpoint or component it affects - the steps to reproduce it, in an order that works - what an attacker could do with it - how you would like to be credited, or that you would rather not be Write in English. Attach a proof of concept if you have one. Do not include third-party data, and stop as soon as you have demonstrated the issue. ### What we commit to - **Two working days** to acknowledge your report with a human reply. - **Ten working days** to give you our assessment: whether we have reproduced it, how we rate the severity, and what we intend to do. - Regular updates while a fix is in progress, without you having to chase. - Credit in our changelog when the fix ships, if you want it. - A public note on the [changelog](https://capybari.com/changelog/) for any issue that affected customer data, whether or not it was reported externally. We do not run a paid bounty programme yet. We say so rather than implying one and haggling afterwards. ### Safe harbour If you make a good-faith effort to follow this policy, we will not pursue or support legal action against you, and we will say so in writing if a third party comes asking. Good faith means: - you test only against accounts and data you own - you do not degrade the service for anyone else - you do not access, alter, copy or retain other customers' data - you give us reasonable time to fix the issue before you publish If you are unsure whether a test crosses one of those lines, ask us first. We answer quickly. ### In scope - `capybari.com` and the marketing site - the Capybari application and its API - authentication, session handling and multi-tenant isolation - credential storage, deployment execution and investigation access levels ### Out of scope - findings from automated scanners with no demonstrated impact - missing hardening headers, cookie flags or TLS configuration with no exploitable consequence - rate limiting, denial of service, volumetric or stress testing - social engineering, phishing or physical attempts against our staff or suppliers - vulnerabilities in your own connected repositories, servers or deploy commands — we will still tell you about them, but they are yours to fix - reports that depend on a compromised device or a prior credential leak ### Contacting us securely Ask on the first email and we will send a PGP key for the follow-up. Please do not post details in a public issue tracker, in Discord or on social media before we have replied. ## What we do not have The gaps, stated before you ask If any of the following is a hard requirement for you today, we are not your platform yet. Better you know now. ### No SOC 2 report. We hold no SOC 2 report of any type. No Type I, no Type II, no bridge letter, and no auditor engaged as of today. SOC 2 Type II sits in the 2027 section of [our roadmap](https://capybari.com/roadmap/). ### No ISO 27001 certification. We are not certified against ISO 27001 or any other information-security standard, and we are not currently in an audit for one. ### No HIPAA or PCI-DSS. We do not offer a BAA, and we are not a PCI-DSS-compliant environment. Do not put protected health information or cardholder data into requests, plans or reports. ### No contractual uptime SLA. We publish live platform health on our [status page](https://capybari.com/status/) and we do not sign availability terms or pay service credits. An uptime SLA is on [our roadmap](https://capybari.com/roadmap/) for 2027. ### No SSO, SAML or SCIM. Sign-in is per user; there is no enforced identity-provider login and no directory provisioning. SSO with SAML is scheduled for Q4 2026 on [our roadmap](https://capybari.com/roadmap/). ### No dedicated tenancy, and no on-prem runner. Every customer runs on shared, multi-tenant infrastructure. Enterprise tenancy and an on-prem runner are in the 2027 and Considering sections of [our roadmap](https://capybari.com/roadmap/). The [pricing page](https://capybari.com/pricing/#enterprise) carries the same list. ## Questions What people ask before connecting a repository Running a security review of us? [Send your questions](https://capybari.com/contact/?topic=Security+review) — we answer in writing. ### Do you train models on my code? No. Your repositories are cloned so agents can run the work you asked for. We do not train models on your code, your requests, your plans, your reports or your run logs. Work sent to model providers goes under agreements that forbid training on it, and on any plan you can supply your own subscription or model keys and cut us out of that relationship entirely. ### What can an agent actually reach? The repositories connected to the project its task belongs to, on its own branch in its own worktree — and, if you have defined one, the deployment target for that project. It cannot reach another project's repositories, another customer's anything, or a server you have not connected. The [access model](#access-model) above sets out each level. ### Can an agent push to my default branch? Not directly. Work happens on a task branch. Reaching your default branch requires the review gates you configured to pass and a merge step to succeed. Mark any role as requiring human review and everything downstream stops until a person approves — at every autonomy level, including Autonomous. ### How are my SSH keys and git tokens stored? Encrypted at rest, and never shown again once saved: not in the interface, not in a report, not in live run output. They are used to clone the repositories you connected and to run the commands you defined on the deployment target you connected. Revoke them on your side at any time and our access ends immediately. ### What happens if a deployment goes wrong? Your health check fails, your rollback command runs against the last commit known to be healthy, and an investigation opens with read-only access. The investigating agent reads logs and diagnostics, writes up the cause and can open a follow-up request with the fix. That fix is planned, reviewed and deployed like any other work. An incident does not create a shortcut. ### Can I use Capybari without giving it a server? Yes, and plenty of teams do. Without a deployment target the platform plans, builds, reviews and reports — and stops at the merge. You then ship it however you ship things today. Deployment access is something you add when you want it, not a condition of using the product. ### Who at Capybari can see my code? Our staff do not read customer repositories to answer support questions. Where debugging genuinely needs access, we ask you first and the access is time-boxed. We are a small company and we will not pretend to controls we have not built: read the [gaps](#gaps) above for the assurance work we have not yet done. ### Is my data isolated from other customers? Projects, repositories, teams and deployment targets belong to one account, and every request is checked against that ownership before anything runs. The infrastructure underneath is shared. We do not offer dedicated tenancy today, and we are not going to describe logical separation as though it were physical separation. ### Where is the platform hosted? On our own infrastructure at Contabo and Vultr, in Europe and the United States. Your code is deployed wherever your servers are — we run the commands, you own the hosts. We do not offer a choice of region for the platform itself yet. Multi-region deployment targets are on [the roadmap](https://capybari.com/roadmap/) for Q4 2026. ### How do I report a vulnerability? Email [security@capybari.com](mailto:security@capybari.com). The [disclosure policy](#disclosure) above covers scope, our response times, safe harbour and what falls outside it. We acknowledge within two working days and give you an assessment within ten. ## Start at Manual. Grant access as you earn trust. Connect one repository, leave the project on Manual, and approve every step by hand. Add a deployment target the week you want one, and not before. No card required · Read-only by default · Revoke our access from your side, any time --- # Solutions URL: https://capybari.com/solutions/ See how Capybari fits four teams: internal tools nobody owns, agencies running many clients, startups without a full org chart, and founders who cannot read a diff. ## Solutions Find your team on this page Capybari runs the same pipeline for everyone. A request gets planned, Capy builds 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. Manual autonomy until you say otherwise Your repositories, your servers No card required ## 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. ### 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 — or by an agency now on to their next client, or by AI a year before anyone thought to write a test for it. 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. ### 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 not enabled the hat a plan named, the work is done under the one that covers 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. ### 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 tasks can run at once and none 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. ### 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. ## How it works You're the only human on the team. You describe what you want in plain English. One AI agent with a department's worth of skills plans it, builds it, checks it and ships it — and comes back to you only when a decision is genuinely yours. ### Your customers can pay by card. Tested, reviewed and watched. If it breaks, it is put back the way it was within about a minute — and someone starts working out why before you have noticed. ## 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. ## Objections The question your segment actually asks Your situation not on the list? [Describe it to us](https://capybari.com/contact/) — a person replies. ### 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. ### 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. ### 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 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 QA and Security Engineer, then relax it once they have watched a few requests go through untouched. ### We are pre-revenue. Is there a version we can afford? Reading is free. Point Capy at your code and it writes back a plain-English description of the system, with no card — we pay for that read. Changing things is $50 a month for the first project and $40 for each after, and the AI work runs on your own subscription. [The detail is here](https://capybari.com/pricing/). ### 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. ### 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](https://capybari.com/security/) sets out the rest. ## 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. Free · no card · Capy reads your repositories and writes you a plain-English description of your own software --- # Status URL: https://capybari.com/status/ Check whether Capybari is working, what broke recently, and what we changed afterwards. Checked by a person, honest about not having a probe, and no SLA promised. ## Status Is it working? The current state of every service, and how we check it. We do not run a monitoring probe yet, so there are no uptime percentages here — we would rather show you nothing than a number nobody measured. ## Bars cover the last 90 days, one bar per period, newest on the right. These are **observed** figures describing what happened. They are not a service level agreement, they carry no remedies, and we do not offer one — see the [roadmap](https://capybari.com/roadmap/) for where a contractual SLA sits. ## Definitions What each status level means So that "degraded" means the same thing on this page every time. ### Operational The service is doing what it is supposed to, at normal speed. This is the only level at which we say nothing is wrong. ### Degraded The service works, but slowly or unreliably — retries, queueing, longer waits. Your work completes; it takes longer than it should. A single slow health check counts here. ### Partial outage Some part of the service is unavailable, or it is unavailable for some customers. Example: runs dispatch normally but deployment runs cannot start. ### Major outage The service is unavailable for most or all customers. Agent runs do not start, and anything mid-flight is held rather than abandoned. We post here first and write to affected teams next. ### Maintenance Planned work with a known window, announced in advance. We schedule it outside European and North American working hours, and we never begin maintenance while a deployment run is in flight. ## How this page is made Two things you should know before trusting it ### This page is updated by hand. There is no automated feed behind it yet. A person checks the services and edits the page, which means it can lag reality by minutes during an incident and it will never update at 4am on its own. Treat the product itself as the authority on whether your run is moving. An automated status feed, with subscriptions and a machine-readable endpoint, is on the [roadmap](https://capybari.com/roadmap/). ### Observed uptime is not a promise. The percentages above describe what we measured. They are not a commitment, they carry no service credits, and no contract refers to them. We do not offer a contractual uptime SLA today and we say so on the [pricing page](https://capybari.com/pricing/) as well as here. ## Seeing something we are not? Tell us what you are seeing and roughly when it started. Include a run or deployment reference if you have one. A person reads it. Incidents written up within two working days · No blame, named systems --- # Terms of Service URL: https://capybari.com/terms/ The terms governing use of Capybari: what a plan buys, how credits are spent, your ownership of your code, acceptable use, availability and liability. ### Written in plain English, on purpose. These terms are meant to be read rather than survived. Section 5 is the one that matters most — what you are responsible for when you let software deploy to your own servers — and section 11 says plainly what we do not promise. If anything here reads as evasive, [tell us](https://capybari.com/contact/) and we will rewrite it. ## Terms of Service ## 1. Agreement These terms are a contract between you and **Dackapps LLC**, a limited liability company registered in the State of Delaware, United States, company number **2505215**, registered office 16192 Coastal Highway, Lewes, Delaware 19958. Dackapps LLC builds and operates **Capybari**. The company and the product have different names; where these terms say "we" or "us" they mean Dackapps LLC, and where they say "the platform" they mean Capybari. By creating an account, or by using the platform, you accept these terms. If you are accepting on behalf of an organisation, you confirm you have authority to bind it, and "you" means that organisation. If you do not accept these terms, do not use the platform. ### 1.1 Definitions - **Platform** — the Capybari web application, API, agent execution environment and supporting services. - **Account** — your organisation's tenancy on the platform, including its users. - **Customer content** — your code, repositories, requests, prompts, configuration, credentials, data and anything else you supply or connect. - **Output** — plans, diffs, commits, branches, reports, investigation summaries and any other material the platform produces for you. - **Agent run** — one execution of one task or plan by one agent, which is the unit we meter. - **Deployment target** — a host you define, with a deploy path, deploy command, health check, diagnostics command and rollback command. - **Review gate** — a point where work stops for human approval, because you set a role to require review or because your autonomy level requires it. ## 2. The service Capybari is a managed AI engineering platform. You file a request on a board. A project manager agent plans it into tasks with owners and dependencies. Capy builds each task on its own branch in its own git worktree. Review gates you configure stop work for a human. Where you have configured a deployment target, the platform deploys to infrastructure **you** control over SSH, runs your health check, and runs your rollback command if the health check fails. When something fails in production, an investigation can open with read-only access by default. The platform's behaviour depends on the autonomy level you set — Manual, Supervised or Autonomous — and on the review gates you configure. You choose how much runs without you. Two things follow from that design, and we state them plainly: - **The platform produces software.** Software has defects. Output is not guaranteed to be correct, secure, complete or fit for any particular purpose. It is your responsibility to review it. - **The platform acts on infrastructure you own.** It does what your commands tell it to do, on the hosts you point it at, with the credentials you supply. We may change, add to or remove features. If a change materially reduces functionality you rely on, we will give notice under section 15. ## 3. Accounts and eligibility - You must be at least 18 years old and legally able to enter a contract. - You must give accurate account and billing information and keep it current. - You are responsible for your account credentials, for all activity under your account, and for the acts and omissions of your users. - Tell us at security@capybari.com as soon as you suspect unauthorised access. - You must not share a single user login between people. Add users instead. - We may refuse, suspend or close an account where these terms are breached. ## 4. Plans, credits and payment ### 4.1 What a plan buys Pricing is described on the [pricing page](https://capybari.com/pricing/). Capybari is licensed **per project**: a licence buys capacity for one project — the storage we hold for it, the number of repositories it may connect, how many of its tasks may run at once, and how many deployment targets it may have. A project that exceeds that capacity consumes as many licences as it needs. Reading a codebase and producing its map is free and is not licensed. **A licence does not include an allowance of agent runs**, and there is no monthly quota to use up or reset. Where a project exceeds its capacity during a billing period, work already in progress completes and new work is not accepted until capacity is added. Plans and prices are those published on the [pricing page](https://capybari.com/pricing/) at the time you subscribe, and all amounts are in **US dollars**. ### 4.2 Paying for the AI work The work itself is executed by AI models, and you choose what pays for it: - **Your own provider account.** Connect your own subscription or API key and the work runs on it. Your use is then governed by your agreement with that provider, and we charge nothing in addition to your plan fee. - **Capybari credits.** Buy credits in advance and the work spends from that balance. ### 4.3 How credits are spent One agent run is one execution of one task or plan by one agent. Before a run starts, an estimate of its cost is reserved against your balance; when it finishes, the reservation is released and the actual cost is settled. A run that fails because of a fault in the platform is not charged. A run that fails for a reason within your control — a failing build, a failing test, a rejected review, a failing health check — is charged, because the work was performed. Your balance and your usage are visible in the application. Credits are purchased in advance and are not billed in arrears. If your balance reaches zero, runs stop until you add credits or connect your own provider account; work already in progress is not discarded. **Credits do not expire** while your account is open. If you close your account with credits unspent, write to support@capybari.com within 30 days and we will refund the unspent balance. ### 4.4 Payment Plan fees are charged in advance for each billing period. Credits are charged at the time of purchase. Fees exclude VAT and any other applicable taxes, which are added where required. Payment is taken by our payment processor; we do not store card details. If a payment fails we may retry it and may suspend the account until it clears. ### 4.5 Renewal and cancellation Subscriptions renew automatically at the end of each billing period until cancelled. You can cancel at any time in the application. Cancellation takes effect at the end of the current billing period; you keep access until then. Except where the law requires it, fees already paid are not refundable, and we do not refund part-used periods. This does not affect any statutory right you have that cannot be excluded — in particular, consumers in the United Kingdom and the European Union keep their cancellation and refund rights under local law, and where those conflict with this section, local law wins. ### 4.6 Price changes We may change prices. Existing customers get at least **30 days'** notice by email before a change applies to their renewal. If you do not accept the new price, cancel before it takes effect. ## 5. Your responsibilities This section matters more than any other. Read it. - **You own your code.** You own your repositories, your servers, your data and your accounts with third parties. Nothing here transfers ownership to us. - **You are responsible for what you authorise the platform to deploy.** You define the deployment target, the deploy path, the deploy command, the health check and the rollback command. You set the autonomy level. You decide which roles require human review. When work ships, it ships because your configuration allowed it to. - **You are responsible for the credentials you supply.** Give the platform the narrowest access that does the job. Rotate credentials when people leave. Do not connect a host you are not entitled to change. - **You must review output before it matters.** Read the plan. Read the diff. Read the completion report — Summary, Files Modified, Risks, Assumptions, Recommendations, Blockers. Keep review gates on for anything that touches money, personal data, authentication or production. - **You are responsible for your backups.** Keep your own backups of your repositories and your production data. Automatic rollback returns a deployment target to the last healthy commit; it is not a backup service and it does not restore data. - **You must have the right to the content you connect.** Do not connect code, data or credentials you are not licensed or authorised to use. - **You must comply with the law** that applies to you, including data protection law, export control and sanctions. ## 6. Acceptable use You must not use the platform, and must not permit anyone else to use it, for any of the following. This section applies to requests you file, code you connect, prompts you write and anything you deploy. ### 6.1 No unlawful use Do not use the platform to break the law, to help anyone else break the law, or to produce anything unlawful. That includes fraud, harassment, stalking, defamation, child sexual abuse material, and content that infringes sanctions or export controls. ### 6.2 No malware or exploitation tooling Do not use the platform to write, assemble, test, obfuscate or distribute malware, ransomware, keyloggers, credential stealers, botnet infrastructure, spam infrastructure, exploit kits, or tooling whose purpose is to compromise systems you do not own or have written permission to test. Security work on your own systems, and authorised penetration testing you can evidence, is permitted. ### 6.3 No circumventing review gates to harm third parties Do not disable, bypass, script around or otherwise defeat review gates, approval steps or the platform's safety behaviour in order to push work that would harm a third party, deploy to a system you are not authorised to change, or conceal what was shipped from the people accountable for it. You may configure your own autonomy level for your own systems; that is not the conduct this clause covers. ### 6.4 No resource abuse Do not use the platform for cryptocurrency mining, distributed computation unrelated to your own software projects, load generation against third parties, proxying or relaying traffic for others, or bulk automated access designed to exhaust shared capacity. Do not run agent runs in patterns intended to evade metering. Do not attempt to access another tenant's data, disrupt the platform, probe it for vulnerabilities without authorisation, or reverse engineer it except to the extent the law permits and cannot exclude. ### 6.5 No infringement Do not use the platform to infringe anyone's intellectual property, to strip licence notices, to launder proprietary code through a rewrite, or to breach the terms of an open source licence that applies to code you connect. ### 6.6 No unauthorised infrastructure **Do not connect, deploy to, or act on any host, repository, account or system that you do not own or do not have documented authorisation to change.** You warrant that every deployment target you configure is under your control or covered by written permission from the person who controls it. This is the single rule most likely to cause real damage if broken. ### 6.7 Enforcement We may investigate suspected breaches and may suspend access under section 14. We will use the least disruptive measure that addresses the problem, and will tell you what we found unless the law prevents us. Report abuse to security@capybari.com. ## 7. Intellectual property ### 7.1 Yours You retain all right, title and interest in your customer content and in the output the platform produces for you. To the extent we hold any rights in output produced for you, we assign them to you. You grant us a non-exclusive, worldwide, royalty-free licence to host, copy, transmit, execute and display your customer content **solely** to provide the platform to you, to support you, and to meet our legal obligations. That licence ends when the content is deleted. We do not use your code, prompts, run logs or reports to train models. See the [Privacy Policy](https://capybari.com/privacy/). ### 7.2 Ours We retain all right, title and interest in the platform itself, including its software, interfaces, documentation, role contracts as distributed by us, trademarks and brand. These terms grant you a limited, non-exclusive, non-transferable, revocable right to use the platform during your subscription, and nothing else. ### 7.3 Feedback If you send us suggestions, we may use them without obligation or payment. We will not identify you as their source without your permission. ### 7.4 No exclusivity in output Machine-generated output is not unique to you. Another customer may receive similar output for a similar request. We make no claim that output is original, novel or free of third-party rights, and you should review it accordingly. ## 8. Confidentiality Each party may receive information the other treats as confidential. Each party will protect the other's confidential information with at least reasonable care, use it only to perform this contract, and disclose it only to people who need it and are under equivalent duties. This does not apply to information that is public through no fault of the recipient, was already known without a duty of confidence, is independently developed, or must be disclosed by law — in which case the recipient will give notice where it is lawful to do so. Your customer content is your confidential information. ## 9. Third-party model providers The platform sends prompts and context to third-party model providers to produce output. The providers we use are **Anthropic**, **OpenAI** and **OpenRouter**. Work sent to them goes under agreements that forbid training on it, and you can connect your own provider account instead, on any plan, in which case your use is governed by your agreement with that provider rather than ours. See the current terms. We configure those providers to exclude content sent through our accounts from model training, and we require that exclusion contractually. Provider behaviour, availability, latency and model versions are outside our control. We may change providers or models to keep the service running or to improve results; where a change materially affects the service we will give notice under section 15. Per-project and per-request model and effort overrides are available in the application, so you can pin behaviour where it matters to you. ## 10. Availability We work to keep the platform available and publish its current state on the [status page](https://capybari.com/status/). **We do not offer a contractual service level agreement.** There is no uptime commitment, no availability percentage and no service credit scheme in these terms today. If that changes we will publish the terms of it; until then, do not rely on any availability figure, including any figure shown on the status page, as a contractual promise. The platform may be unavailable for planned maintenance, emergency maintenance, third-party failures, or any of the ordinary reasons software stops working. We will give reasonable notice of planned maintenance where we can. ## 11. Disclaimers To the fullest extent the law allows, the platform and all output are provided **"as is"** and **"as available"**, and we exclude all warranties, conditions and representations not expressly stated in these terms, including implied warranties of merchantability, satisfactory quality, fitness for a particular purpose and non-infringement. In particular, we do not warrant that: - output will be correct, secure, complete, compilable or fit for any purpose; - the platform will be uninterrupted, timely or error-free; - defects will be corrected within any particular time; - a review gate, health check or rollback will catch every problem. Automatic rollback returns a deployment target to the last healthy commit. It cannot undo external side effects — emails sent, payments taken, third-party API calls made, or data written by a released change. Nothing in this section excludes a warranty the law does not permit us to exclude. ## 12. Limitation of liability Nothing in these terms limits or excludes either party's liability for death or personal injury caused by negligence, for fraud or fraudulent misrepresentation, or for any other liability that cannot lawfully be limited. Subject to that: - Neither party is liable for indirect or consequential loss, loss of profit, loss of revenue, loss of anticipated savings, loss of business, loss of goodwill, or loss or corruption of data, however arising. - Our total aggregate liability arising out of or in connection with these terms, whether in contract, tort (including negligence), breach of statutory duty or otherwise, is limited to the fees you paid us in the **12 months** immediately before the event giving rise to the claim, or **US$100** where that is greater — the floor exists because the platform can be used without paying us anything, and a cap of zero is not a cap. The platform is priced on the assumption that these limits apply. They are a material part of the bargain. ## 13. Indemnity You will indemnify us against claims, damages, losses and reasonable costs arising from: - your customer content, including any claim that it infringes third-party rights; - your use of the platform in breach of section 5 or section 6; - anything you deployed, or authorised the platform to deploy, to any system; - your breach of law in connection with the platform. We will tell you promptly about any claim, let you control its defence with counsel of your choosing, and give you reasonable assistance at your cost. You will not settle a claim in a way that imposes obligations or admissions on us without our written consent. ## 14. Suspension and termination ### 14.1 By you Cancel at any time in the application, as set out in section 4.5. ### 14.2 By us We may suspend or limit access, in whole or in part, where: - payment is overdue; - we reasonably believe section 6 has been breached; - a user's activity threatens the security, integrity or availability of the platform or another customer; - the law or a competent authority requires it. Where it is practical and lawful, we will warn you first and give you a chance to fix the problem. For urgent security or legal issues we may suspend immediately and tell you straight afterwards. We may terminate for material breach that is not remedied within **30 days** of written notice, or immediately where the breach cannot be remedied. ### 14.3 Effect On termination your right to use the platform ends. You may export your customer content for **30 days** after termination, after which we delete it in line with the retention periods in the [Privacy Policy](https://capybari.com/privacy/). Your repositories and your servers remain yours throughout; the platform is not the system of record for your code. Sections that by their nature should survive — including 7, 8, 11, 12, 13, 16 and this section — survive termination. ## 15. Changes to these terms We may change these terms. When we do, we change the "last updated" date at the top. For material changes we will email account holders at least **30 days** before they take effect. If you do not accept a material change, cancel before it takes effect; continued use after that date is acceptance. Changes required by law or needed to address a security risk may take effect sooner, and we will say why. ## 16. Governing law These terms, and any dispute arising out of or in connection with them, are governed by the laws of the **State of Delaware, United States**, without regard to its conflict-of-laws rules, and the state and federal courts located in Delaware have exclusive jurisdiction. This does not deprive you of the protection of mandatory provisions of the law of the country where you live, and does not override must be confirmed by a solicitor against the final registered entity, and against any mandatory consumer protections that apply to customers outside England and Wales. ## 17. General - **Entire agreement.** These terms, the [Privacy Policy](https://capybari.com/privacy/), the [Cookie Policy](https://capybari.com/cookies/) and any order form or data processing agreement we sign form the whole agreement between us. - **Order of precedence.** A signed order form or data processing agreement prevails over these terms to the extent of any conflict. - **Assignment.** You may not assign these terms without our written consent. We may assign them to a successor in a merger or sale of the business. - **Subcontracting.** We may use subcontractors and sub-processors; we remain responsible for their performance. - **Severability.** If a provision is unenforceable, the rest continues in force. - **No waiver.** Not enforcing a provision is not a waiver of it. - **Third parties.** No one other than you and us has rights under these terms. - **Force majeure.** Neither party is liable for failure caused by events outside its reasonable control. - **Notices.** We give notice by email to the account's registered address, or in the application. You give notice to hello@capybari.com and to the registered office. ## 18. Contact Questions about these terms: **hello@capybari.com** Billing: **support@capybari.com** Security and abuse: **security@capybari.com** Data protection: **privacy@capybari.com** Dackapps LLC, 16192 Coastal Highway, Lewes, Delaware 19958, United States. Company number 2505215. VAT and other tax identifiers are shown on your invoice and available on request. Last updated 5 September 2026 --- # Abandoned codebase URL: https://capybari.com/use-cases/abandoned-codebase/ Your developer left or the agency stopped replying. Capy takes over the code you already have — no rewrite. It reads it, plans, and you approve. ## For founders who inherited their own product You own the product. You just can't move it anymore. The developer who built it is gone. The agency that delivered it stopped replying. The code works, but every change feels like defusing a bomb. **You do not need a rewrite. You need someone to take it from here.** Capybari reads the code you already have, plans changes in plain English, and ships them only after you approve. No card required Nothing runs until you approve it Your repository, your servers ## Sound familiar? The developer left, or the agency disappeared Neither of these is a failure of nerve. They are what happens when the person who held the whole thing in their head stops answering, and the product they left behind keeps running without them. Built it with an AI yourself and daren't touch it now? That is a different problem with a different answer — [start here](https://capybari.com/use-cases/ai-generated-code/). ### The developer left They knew how everything worked. Nobody wrote it down. Now every question you have about your own product starts with "I think it does…" and ends with you hoping you are right. The code is not lost. The person who could read it is. ### The agency is gone You paid for the code. You own it. But you have no idea what is in it, what it depends on, or what will break if you touch it. And every quote from a new agency opens with "we would recommend a rebuild" — which means paying twice for software you already have. ## Abandoned codebases, specifically Same product. Three stories that end the same way. None of these is a greenfield project, and none of them came with documentation. They are the normal input, not the difficult one. Capy reads the project before it plans, so what it knows about yours comes from your code rather than from an assumption about how it ought to have been built. ### The ex-agency Shopify app Delivered, invoiced, handed over as a zip and a login. It still takes orders. Nobody has opened the repository in fourteen months and the agency's address bounces. ### The SaaS after the contractor vanished Paying customers, a Stripe integration somebody set up once, and a contractor who stopped replying mid-sprint. The last commit message is "wip". ### The internal tool with zero docs Forty people depend on it daily. It was written by someone who left in 2023, has no README, no tests, and a deploy process that lives in one person's shell history. ## Take over existing code How Capy takes over an existing codebase The order matters more than any single step. Nothing is written until the thing has been read, and nothing ships until you have seen the plan in words you can check. ### You attach the repository GitHub, GitLab, Bitbucket, or any git remote over SSH. If the code was handed over as a folder or a zip and never lived on a git host, upload it and Capy makes it a repository — which is how a fair number of inherited codebases actually arrive. Either way, Capy works on branches inside your repository, not on a copy in ours. ### Capy reads the project Before changing anything it reads the architecture, the conventions the project already follows, its dependencies and how it is put together. What it learns persists. You are not re-explaining your own codebase every session. ### You describe the outcome "Customers in Germany can't check out." "Add a monthly plan." A sentence is enough. You never have to describe how to do it. ### Capy plans the change in plain English You read the plan. You can tell from it whether it understood you — which is the whole point of writing it down before writing any code. Approve it, reject it, or say what it missed. ### Capy builds and tests it Each task runs on its own branch in its own isolated worktree. Tests, code review and a security pass happen before the merge — not after somebody notices in production. ### Capy deploys it — and watches Deploy to your own servers with a health check and an automatic rollback if it fails. Then Capy keeps watching. If something breaks at two in the morning, an investigation opens on its own with read-only access to logs and diagnostics. ## What the first week looks like From "nobody can touch this" to a change shipped Not a migration plan and not a discovery phase. The point of the first week is one safe change in production, so you find out what this is like before you commit anything to it. No rewrite, no migration, no discovery phase you pay for before anything moves. ### Day one #### You attach the repository Connect the git remote — or upload the folder you were handed — and grant read access. Nothing is changed and nothing is deployed. #### Capy reads the project It works through the architecture, the conventions, the dependencies and how the thing is put together — before you have asked it for anything. #### You get the first brief A description of your own software in plain English. For a lot of people this is the first time anyone has written that down. ### Day two #### You name one stuck thing The fix you have been putting off. A sentence is enough. #### You approve the first plan Read it and you can tell whether it understood you. Approve it, reject it, or say what it missed. Nothing runs before that. ### By the end of the week #### The first safe change ships Built on its own branch, tested, reviewed, and deployed behind a health check with rollback armed. You approved it before it went. #### And you know where you stand One change through the whole path tells you more about whether this works for your codebase than any amount of evaluation. ## You approve. You don't supervise. Nothing ships that you did not agree to Handing over code you do not fully understand is the part that is actually frightening. These are the three things that make it survivable, and none of them is a setting you have to remember to switch on. The whole model, including what an investigation may and may not touch: [read the security and governance page](https://capybari.com/security/). ### Before It thinks before it changes Planning and architecture come first. You see the plan before any code is written, and in Manual mode nothing proceeds until you say so. ### During Every task gets its own branch Nothing touches your default branch until the review gates you configured have passed. Any role can be marked as requiring human review — at every autonomy level, with no exceptions. ### When it is unsure It knows when to ask you Technical calls it makes. Business calls it escalates. If payment retry behaviour is ambiguous it stops and asks. If a variable is missing on a production host it investigates and opens a request — it does not guess. ### Your repository Capy works on branches inside your own git remote. Not a copy in ours. ### Your servers It deploys where you tell it to, or nowhere. Write access to a production host is a separate grant. ### Your approval You read the plan before anything is written, and nothing merges until the gates you set have passed. ## Convinced? Give Capy one problem. Read the plan it writes back. Nothing runs until you say so. You need a git repository and one stuck request. Nothing else to prepare. ## Built for exactly this situation You do not need a rewrite to take over existing code You have three options when you inherit a codebase you cannot move. **Rebuild it from scratch** and lose everything you have already paid for. **Hire another agency** and wait six weeks for a quote that begins by recommending the first option. Or **hand it to something that reads it first**, plans in plain English, and only ships what you approve. That third option is what Capybari is for. It is also the only one of the three that leaves you knowing more about your own product at the end than you did at the start — because the plan it writes before each change is a description of how your software actually works. ## The objections worth taking seriously Questions people ask about an abandoned codebase Still circling something? [Ask us directly](https://capybari.com/contact/) — a person replies. ### Can it really work on a codebase nobody understands? That is the case it was built for. Agents read your conventions before they plan, and every role contract instructs the specialist to make the smallest safe change and reuse the patterns already there rather than introduce new ones. A codebase nobody understands is not an unusual input — it is the normal one. ### What if the code is genuinely bad? Capy does not judge it, and it will not quietly rewrite it either. It reads what is there, plans the smallest safe change and verifies before shipping. Where something is too risky to touch, that appears in the plan you read — before any of it runs. ### Do I have to give it access to my production servers? Only if you want it to deploy. Plenty of teams run Capybari for planning and building alone and deploy by hand as they always have. A deployment target is an SSH host you define, with a deploy command, a health check and a rollback command you write. Write access to a production host is a separate, explicit grant and is never the default. ### What happens if it breaks something? Your health check fails, your rollback command runs, and an investigation opens on its own. An agent with read-only access reads the logs and diagnostics and writes up the cause, then opens a follow-up request with the fix. It cannot change your server unless you grant that explicitly. ### What does it cost to find out? Nothing. The free plan carries one project and your own code, with no card required — enough to point it at a repository and read the first plan it writes back. [The plans are here](https://capybari.com/pricing/) when you want the detail. ## Related situations If this is not quite you ### You carry client systems, not one A studio on the hook for a portfolio nobody is free to maintain. [Start here](https://capybari.com/use-cases/agencies/). ### An AI shipped it and skipped the engineering Claude, Cursor or Lovable got it live, and it has no tests, review or pipeline. [Start here](https://capybari.com/use-cases/ai-generated-code/). ## Start here Give Capy one problem and see what comes back Not the whole backlog. One thing that has been stuck — the fix you have been putting off, the feature nobody is free to build. Point Capy at the code, describe the outcome, and read the plan it writes back. Nothing runs until you say so. Free · no card · Capy reads your code and writes back a plain-English description of the system, before you decide anything ### email Work email ### company Company or project name --- # Agencies & studios URL: https://capybari.com/use-cases/agencies/ Client systems you are on the hook for, and nobody free to maintain them. Capybari takes custody: gates, deploys, rollback. $50 a month per system, $40 after the first. ## For agencies and studios You are on the hook for systems nobody is free to look after. Ten, twenty, forty client products — some you built, some you inherited. The clients keep asking for changes. The work is unbillable or barely billable, it interrupts project work, and it lands on whoever is least busy that week.\n\n**Capybari takes custody of those systems**, so the retainer keeps paying without a developer attached to it. $50 a month per project, $40 after the first Deploys to your client's own servers Volume steps down across a portfolio ## The actual problem Maintenance is a margin problem wearing a technical costume Nobody in a studio needs convincing that maintenance is painful. What is worth saying out loud is where it shows up in the accounts. None of that is a tooling problem. It is a staffing problem you cannot solve at the margin the work carries. ### It costs project time The developer doing it is off something billable A two-day maintenance job is two days not on a project with a rate attached. It rarely appears as a cost because it never gets an invoice line — it shows up later, as a project that ran over. ### It lands badly It goes to whoever is least busy, not whoever knows it Which means someone reads a codebase they have never seen, under time pressure, for work that is not going to be billed at a rate that justifies the reading. ### It accumulates There is at least one repo nobody has opened in a year Still running, still the client's product, still yours to answer for. Every month it is untouched, the cost of touching it goes up and the person who understood it is further away. ## The offer Keep the retainer. Skip the salary behind it. Capybari takes on the maintenance of a client system: it learns the codebase and keeps that understanding current, plans changes in plain English, builds them through gates, deploys to the client's own servers, and notices when something breaks.\n\n**$50 a month for the first client system and $40 for every one after it** — fifteen systems is $610 a month, not $750. Annual billing is ten months for twelve. Viewers and collaborators are free, so putting your whole team and the client in to watch costs nothing, and the AI work runs on your own subscription at no mark-up.\n\nA dormant system still costs something, because the value is that it is watched and the understanding stays current — not that changes happened this month. [Tell us what you are carrying](https://capybari.com/contact/) and we will tell you what it costs. ## Start with the one nobody has opened Point it at a dormant client project and read what comes back The free thing here is not a trial. It is a document: Capy reads the repositories and writes a plain-English description of the system — what it is, what it is built from, how the parts relate, and what is wrong with it. ### Costs you nothing And needs no client conversation If you hold the code, you can run it today. No permission to ask for, nothing to explain to a client, no commitment on the other side of it.\n\nPick the project you would least like to be asked about. That is the one where the document is worth the most. ### And it is billable work You could plausibly invoice for the output An audit of an inherited system, written down, is something studios charge for. Whether you bill it, hand it to the client, or keep it for your own estimating is up to you.\n\nIt is also the only claim on this page you can check against your own code without taking our word for anything. ## What custody actually means The part you are currently doing at 11pm This is the section an agency principal skips to, so it is the one with mechanisms in it rather than adjectives. The full model, including exactly what an investigation may and may not touch: [the security and governance page](https://capybari.com/security/). ### Before the merge Gates that can reject, not just produce Architecture, code review and a security pass run before anything joins the client's default branch. Any role can be marked as requiring a human — yours — and dependent work stops until you approve it, at every autonomy level. ### The deploy To the client's servers, with a rollback armed A deployment target is an SSH host plus four things you write: a deploy path, a deploy command, a health check and a rollback command. Because the commands are yours, it fits the client's existing setup rather than requiring a new one. ### Afterwards The investigation opens itself A failed health check rolls the deploy back on its own and opens an investigation with read-only access to logs and diagnostics. You get the cause written up and a follow-up request containing the fix.\n\nIt cannot change the client's server unless you grant that explicitly. Read-only is the default, not a setting. ## What studios ask Running client work through Capybari ### How is this priced across a portfolio? $50 a month for the first system and $40 for each one after it, so fifteen comes to $610 rather than $750, and annual billing is ten months for twelve. One licence covers a system up to 2 GB of code across 5 repositories, with 3 tasks at once and 2 deployment targets; a heavier system uses more than one. Viewers and collaborators are free. [The detail is here](https://capybari.com/pricing/). ### Do we have to give access to client production servers? Only for the systems you want deployed. Plenty of agencies run planning and building only and deploy through their existing process. Write access to a host is a separate, explicit grant and is never the default. ### What happens when a client system breaks at 2am? The health check fails, the rollback runs, and an investigation opens on its own with read-only access. You get the cause written up and a follow-up request with the fix — rather than a phone call, and rather than finding out from the client. ### What about a client whose code we did not write? That is the normal case. Capy reads the project before it plans anything, and the role contracts instruct every specialist to make the smallest safe change and reuse the patterns already there. Inherited codebases are the input it was built for. ### Can we bring our own AI subscription? Yes. Compute is separate from the custody price and passed through at cost — bring your own subscription at no markup, or buy credits. It is deliberately not folded in, because a busy month would then look like a price rise. ## Related situations If this is not quite you ### One system, and the person who understood it is gone Not a portfolio — a single product nobody can read any more. [Start here](https://capybari.com/use-cases/abandoned-codebase/). ### An AI shipped it and skipped the engineering It works, and it has no tests, review or pipeline. [Start here](https://capybari.com/use-cases/ai-generated-code/). ## Start here Point Capy at the client project nobody has opened The dormant one. The one you would least like to be asked about this quarter. Capy reads it and writes back a plain-English description of what it is, what it depends on, and what is wrong with it.\n\nIt costs nothing, it needs no client conversation if you hold the code, and it commits you to nothing afterwards. Free · no card · tell us roughly how many client systems you carry and we will come back with what custody would cost ### email Work email ### company Studio name --- # AI-generated code URL: https://capybari.com/use-cases/ai-generated-code/ Claude, ChatGPT, Cursor, Lovable, Bolt, v0 — whichever built it. Capybari adds the engineering layer it skipped: tests, review, deploys. No rewrite. ## For codebases an AI wrote The AI built it. Now nobody wants to touch it. Claude, ChatGPT, Cursor, Lovable, Bolt, Replit, v0 — whichever got you there. It works. But there are no tests, no review, no pipeline, and every change feels like a gamble. **Capybari is not another coding assistant.** It is the engineering layer your codebase skipped: it reads what exists, plans in plain English, builds on isolated branches, and ships only after you approve. Not on a git host? Export the project and upload the folder or zip — Capybari turns it into a repository. What it cannot start from is an idea: there has to be code. Works on your repo, on branches Nothing merges until the gates pass No rewrite required ## You know exactly what happened here The code is not the part that went wrong You prompted your way to a working product. It does what you needed. But somewhere between the first commit and the last, the process that normally happens — tests, review, a real deploy, somebody who owns it when it breaks — got skipped. Not because you were careless. Because you were moving fast, and the AI made it possible to move fast without any of it. Now it works, you are the only person who understands it, and you are not certain you do. ### The history tells on itself Nothing between "initial commit" and production No test run that would have caught the regression. No second pair of eyes on the diff. No gate between the merge and the customers. Every one of those was skippable, which is exactly why they got skipped. ## Pick the one that is you It shipped. That was never the hard part. Carrying a portfolio of these rather than one? An agency's version of this problem is [here](https://capybari.com/use-cases/agencies/). ### Shipped with Lovable It is live and people use it. You have not opened the editor since, because you are not sure what a change would touch. ### Cursor got it to production Working product, real users, and CI never existed. Deploys are you, on a laptop, hoping. ### ChatGPT built the MVP Stripe is the next thing to add, and you do not trust the payments code enough to touch it. ## Engineering workflow for AI-built software AI-generated code is not bad code It is code written without the workflow that makes code safe to change. What it needs is not a rewrite. It needs the things that were skipped: Capybari is that layer. **It does not rewrite your code.** It gives your code the process it never had. **Tests** that catch a regression before a customer does. **Review gates** that stop a change before it merges. **A security pass** before anything reaches production. **Isolated branches** so parallel work cannot collide. **A deployment pipeline** with a health check and a rollback. **Somebody watching** after it ships, and an investigation when it breaks. ## AI-generated codebase management What Capy does with a codebase an AI wrote The same pipeline every project gets. What is different here is only that step two has more to read and fewer conventions to rely on. This is the workflow your AI skipped — not because it could not do it, but because you were not asking it to own the engineering process. That is the job this takes. ### You attach the repository GitHub, GitLab, Bitbucket, or any git remote over SSH. Or upload a folder or zip if it never made it to a host — a lot of prompted-into-existence projects never did. Capy works on branches inside your repository, not on a copy in ours. ### Capy reads the project Architecture, the conventions the project actually follows rather than the ones it should, dependencies, and how it fits together. What it learns persists — you are not re-explaining your own codebase every session, which is the tax you are currently paying to a chat window. ### You describe the outcome "Add a monthly plan." "Fix the checkout bug on mobile." "The export button doesn't work." A sentence is enough. You never have to describe how to do it. ### Capy plans the change in plain English A request becomes tasks with an order, an owner and dependencies. You read it and can tell whether it understood you — approve, reject, or say what it missed. ### Capy builds and tests it Each task on its own branch in its own worktree. Tests, code review and a security pass before the merge, not after somebody notices in production. ### Capy deploys it — and watches To your own servers, with a health check and an automatic rollback. If something breaks at 2am an investigation opens on its own, read-only, and writes up the cause. ## What the first week looks like Small blast radius on purpose Nothing here requires you to hand over the whole codebase on day one. The point of the first week is one gated change, so you can judge the process on something you chose. Everything stays on Manual unless you move it. Nothing dispatches on its own while you are deciding whether you like this. ### Day one #### Attach the repository, or upload the folder Read access is enough to start. No deployment target, no server credentials, nothing to configure on your infrastructure. #### The first brief: what your app actually is Architecture, dependencies, the conventions the code really follows, and where the sharp edges are. For a codebase assembled over months of prompting, this is frequently the most useful artefact of the week. ### Day two #### Name the change you have been avoiding The one whose blast radius you cannot predict. That is the useful test, not a trivial one. #### Read the plan and approve it Tasks, order, owners, dependencies. If it misread the codebase, you will see that here — before anything runs. ### By the end of the week #### One change through the whole gate Isolated branch, tests, review, security pass, merge, deploy, health check. The first time that codebase has had any of it. ## Start with one change you have been avoiding Read the plan it writes back. Nothing runs until you say so. A repository — or a zip of the project — and one request. Nothing else to prepare. ## If you already use Cursor, Copilot or Claude Code Both are useful. The difference is who carries the work. An assistant makes you faster at doing it yourself, and still needs you in the chair for every decision. Capybari is for when the work is no longer writing code — it is owning the engineering workflow around code that already exists. Keep using the assistant. This is not a replacement for the thing that wrote your code — it is the process that was never put around it. Helps you write code | Owns the engineering workflow Needs you at every step | Asks only when it genuinely needs a decision You break down the work | Plans the work, with dependencies and owners You hold the context | Reads the project and keeps what it learns New projects are easiest | Existing, legacy and AI-generated code is first-class Stops when you stop typing | Keeps going while you do something else You check the result | Tests, review and a security pass before merge You deploy and watch | Deploys, health-checks, rolls back, investigates The model is the product | Models are interchangeable intelligence A coding assistant Capybari ## You approve. You don't supervise. Nothing ships that you did not agree to Four mechanisms, not four assurances — followed through one request: *stop failed Stripe webhooks from double-charging customers*. Each is a thing that happens whether or not you are watching. The full model, including exactly what an investigation may and may not touch: [the security and governance page](https://capybari.com/security/). ### It thinks before it changes A plan before a diff Planning and architecture come first. A request becomes engineering tasks with an order and an owner: what changes, where, and in what sequence. You see it before any code is written. ### It does not let agents collide One branch, one worktree, per task Nothing touches your default branch until the review gates you configured have passed and the merge succeeds. Parallel tasks cannot overwrite each other, because they are not sharing a checkout. ### It has people whose job is to say no Architecture, security and review are gates They can reject work, not merely produce it. Any role can be marked as requiring human review; when it is, dependent work stops until you approve — at every autonomy level, with no exceptions. ### It verifies before shipping And keeps watching afterwards Tests, code review and a security pass before the merge. Then a health check on deploy, an automatic rollback if it fails, and an investigation opened read-only against your logs. ## The autonomy question A dial, not a switch Projects start at **Manual**. Nothing runs until you press the button. Move to **Supervised** when the plans stop surprising you — planning starts on its own and work you have approved dispatches itself. Reach **Autonomous** when you trust the gates. Most teams take about three weeks. Review gates and genuine escalations reach a human at every level. You never have to let it run on its own, and you can always turn it back down. This is not a tool that asks you to trust it on day one. It earns it over three weeks, on your code, with your approval at every step. ## The objections worth taking seriously Questions about handing over AI-generated code ### Can it really work on a codebase that was written by an AI? That is the case it was built for. Agents read your conventions before they plan, and role contracts instruct every specialist to make the smallest safe change and reuse existing patterns rather than introduce new ones. AI-generated codebases are first-class, not an edge case. ### What if the code is genuinely bad? Capy does not judge it, and it will not quietly rewrite it either. It reads what is there, plans the smallest safe change, and verifies before shipping. If something is too risky to touch, that appears in the plan. You are not required to clean it up first — that is the opposite of the point. ### Do I have to give it access to my production servers? Only if you want it to deploy. Plenty of teams run Capybari for planning and building alone and never connect a server at all. A deployment target is an SSH host you define, with a deploy command, a health check and a rollback command you write. Write access is a separate, explicit grant and is never the default. ### What happens if it breaks something? Your health check fails, your rollback command runs, and an investigation opens on its own. An agent with read-only access reads the logs and diagnostics, writes up the cause, and opens a follow-up request containing the fix. It cannot change your server unless you grant that explicitly. ### Is my code used to train models? No. Your repositories are cloned so that agents can run the work you asked for, and for nothing else. We do not train models on your code, your requests, your plans or your reports. The detail is on [the security page](https://capybari.com/security/). ### What does it cost to find out? Nothing. The free plan carries one project and your own code, with no card required. [The plans are here](https://capybari.com/pricing/) when you want the detail. ## Related situations If this is not quite you ### Someone who understood the code is gone The developer left or the agency stopped replying, and nobody can read it now. [Start here](https://capybari.com/use-cases/abandoned-codebase/). ### You carry client systems, not one A studio on the hook for a portfolio nobody is free to maintain. [Start here](https://capybari.com/use-cases/agencies/). ## Start here Give Capy one problem and see what comes back Not the whole backlog. One thing — the fix you keep not doing because the blast radius is unknown, the feature you have been putting off because you would have to touch the part you understand least. Point Capy at the code and describe the outcome. Read the plan it writes back. If it has understood your codebase, you will know from the plan; if it has not, you have lost ten minutes. Nothing runs until you say so. Free · no card · Capy reads your code and writes back a plain-English description of the system, before you decide anything ### email Work email ### company Company or project name