New Give Capy a codebase you already have

Your engineering
department. In a box.

Capy is an engineering department that takes a product from idea to production — and can take over software you already have. Bring your idea or your existing code. Capy learns the project, plans the work, assigns the right specialists, builds, tests, reviews, deploys, and watches it in production.

Tell Capy. Watch it go live. Your repositories, your servers Manual mode until you say otherwise

How it works

You bring the idea. Capy takes it to production.

Everything between those two moments belongs to Capybari — planning, building, reviewing, shipping, and watching it afterwards.

You · human The idea, and the approval One sentence to start it. One yes before anything is built. That is your whole part.
You ask You approve
Capybari A full engineering team of AI specialists, working on your repositories and your servers. plansbuildsreviewsshipswatches
It delivers
Live Your product, working A websiteAn online storeA mobile appAn internal toolAn API

Two moments need you. Everything else is handled — including the night it breaks.

Teams shipping with Capybari

Cash Pappa Dackapps Fordle Livegrid.Live Netfilter.Pro

The whole function, not the pieces

Stop hiring the pieces. Get the department.

Shipping software takes more than someone who writes code. It takes planning, architecture, front end, back end, data, testing, security, review, and somebody who owns the deploy at two in the morning. Capy brings all of it as one coordinated organisation — one interface, one engineering department, one accountable workflow.

One request in

You describe the outcome

A department behind it

Fourteen specialists, one organisation

One accountable thread

Nothing falls between people

Existing code welcome

Already have software? Give it to Capy.

Most software work does not start with a blank screen. It starts with a codebase nobody fully understands, dependencies that are years behind, decisions no one wrote down, and a list of things that need to change. Attach the repository and Capy learns the project before it changes anything in it.

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, in which layer, and which specialist takes it.

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

Say what you want changed

Capy

Builds while you watch

You again

See it, then decide

Brief

Run your engineering department in 15 minutes a day

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.

The fifteen minutes

09:00

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

09:15

Back to your actual job

The department works the other twenty-three hours and forty-five minutes. Capy escalates only what genuinely needs your judgement.

The gap

You do not need more code.
You need the expertise to build a product.

Code generation stopped being the bottleneck a while ago. What small teams still cannot staff is everything that happens around the code — the planning, the review, the security pass, the deploy, and the person who gets up when it breaks.

Not a copilot

An organisation, not an assistant

Fourteen specialist roles, each with a written contract defining what it owns and where it must stop. They hand work to each other the way a real team does.

  • A Project Manager — reads your request and writes the plan — in plain English, with owners and dependencies.
  • Governance roles — an architect, a code reviewer and a security engineer who can reject work, not just produce it.
  • Capability substitution — if a role is missing from your team, the work is reassigned to whoever can cover it — and the substitution is recorded, never silent.

Isolation

Every task gets its own branch

Tasks run in parallel, each in its own git worktree on its own branch. No agent can see another's half-finished work, and none of it reaches your default branch until the gates pass.

  • Dependency-aware — a task that depends on another simply waits. The graph is visible on the board.
  • Reversible by construction — an abandoned task is a deleted branch. There is nothing to unpick.
  • Your git history stays legible — one branch per task, one report per branch.

Gates

Decisions that actually need you

Capy handles the engineering decisions — architecture, implementation, testing, dependencies, and technical tradeoffs. It only comes back to you when a decision requires business judgment.

  • You decide what matters — priorities, product behavior, business rules, and decisions that affect your users or your business.
  • Capy handles the how — architecture, implementation, technical tradeoffs, testing, security, and everything required to get the work done.
  • Clear when your input is needed — Capy explains the decision, the options, the implications, and its recommendation before asking you to choose.
  • Nothing important happens by accident — you stay in control of the decisions that require your judgment, while Capy owns the technical execution.

Operations

It deploys. And it stays.

Connect a server over SSH and give Capybari a deploy command, a health check and a rollback command. It merges, ships, checks, and puts things back if the check fails.

  • Automatic rollback — a failed health check restores the last commit known to be healthy. Typically inside a minute.
  • Investigations — a failed deploy opens an investigation. An agent reads the logs, finds the cause and writes it up.
  • The fix becomes a request — the investigation opens the follow-up work itself, linked back to the incident.

The same thing, in detail

Request to production, in five moves

The same pipeline every time. What changes is how much of it you approve by hand.

You file a request

A sentence is enough. "Card payments fail for European customers." Type, priority, done.

It gets planned

The Project Manager reads your codebase and writes a task plan with owners and dependencies. You approve it or edit it.

Specialists build

Tasks dispatch in parallel, each on its own branch, each ending in a structured report.

Gates and merge

The reviewer and the security engineer sign off. You approve anything marked for review. Branches merge.

Deploy and watch

It ships to your server, runs your health check, and rolls back on its own if the check fails.

By the numbers

What is actually in the box

Product facts, not projections. Every figure below describes something shipped today.

14 specialist roles From architect to iOS developer, each with an editable contract.
3 autonomy levels Manual, Supervised, Autonomous. You move up when you're ready.
1:1 branch per task Isolated git worktrees, so parallel work never collides.
0 deploys without a health check A target without a health check cannot be marked healthy.

We publish no customer counts, no "hours saved" and no velocity multipliers until we can show you the method behind them. See our roadmap for what is coming next.

The org chart

Fourteen roles. One board.

Add the specialists a project needs and leave out the ones it doesn't. Work planned for a missing role is reassigned to whoever can cover it.

ED Executive Director
Coordinator
PM Project Manager
Coordinator
ARC Architect
Governance
CR Code Reviewer
Governance
SEC Security Engineer
Governance
BE Backend Developer
Worker
FE Frontend Developer
Worker
FS Full Stack Developer
Worker
DB Database Engineer
Worker
QA QA Engineer
Worker
DEV DevOps Engineer
Worker
UX UI/UX Designer
Worker
IOS iOS Developer
Worker
AND Android Developer
Worker

Every role is governed by a Markdown contract you can read and edit. See how the team works.

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

Connect any git remote. Capybari 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.

Why you can hand it over

An engineering department you can actually trust

Handing work to someone means knowing how they behave when you are not looking. These are the answers to that, not a feature list.

It thinks before it changes

Planning and architecture come first

It does not let agents collide

Every task gets its own branch

It has people whose job is to say no

Architecture, security and review are gates

It knows when to ask you

Technical calls it makes; business calls it escalates

It verifies before shipping

Tested and reviewed before the merge

It watches after shipping

Health checks, rollback, investigations

Bring your own intelligence

Bring the intelligence you already use

Capy is not trying to make its value proportional to how many tokens you consume. Connect the AI subscription or API key you already pay for, and Capy orchestrates the work across it. The models are the workforce. Capy is the engineering department.

Your choice of model

Your key, your provider

What Capy adds

The part a model cannot do alone

Independence

Models change; the department does not

A different category

This is not another coding copilot

Both are useful. They are not the same kind of thing, and the difference is where the work sits — with you, or with the department.

A coding assistantCapy
Helps you write code Owns the engineering workflow
Usually one agent Coordinated specialist roles
You break down the work Capy plans the work
You manage the context Capy learns the project and keeps what it learns
New projects are easiest Existing and legacy projects are first-class
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
You stay involved throughout Brief lets you manage it asynchronously
The model is the product Models are interchangeable intelligence

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.

How far the simplification goes

Software should not require knowing how software works

Speak · Build · See · Ship Capy can present a radically simplified board for someone who should never see a repository, a branch or a deployment setting. *"Make me a game where players dodge falling objects."* — and the engineering happens underneath. Projects, permissions, providers, keys, infrastructure and deployment stay with the adult who set it up, in a guardian's view over what gets built. It is built for child profiles, and it makes a wider point: the simpler the surface gets, the more engineering Capy is absorbing beneath it.

Pricing

Pay for work done, not seats filled

The plan buys capacity. The AI work underneath runs on your own subscription or key at no extra cost, or on Capybari credits if you would rather not bring one. Viewers are free either way.

Free

See it work, on your own code.

$0 forever

1 project · 100 MB · welcome credits to start

Everything you need to see it work:

  • 1 project, 1 repository, 100 MB
  • Import a codebase you already have — Capy reads it and writes down what it is made of
  • 1 run at a time
  • Your own Claude or Codex subscription, or your own API key
  • Plain-English plans with a task graph you approve
  • Every task on its own branch, ending in a written report
  • Community support

Starter

For one team shipping one product.

$7.99 per user / month

3 projects · 1 GB · billed annually, $24 a year less

Everything in Free, plus:

  • 3 projects, unlimited repositories, 1 GB
  • 3 concurrent runs
  • Deploys to your own servers — one target per project, with rollback
  • Auto-deploy — approved work ships without a second press
  • Requests build on each other, so the tenth starts from the ninth's work
  • The Brief, in writing — what moved, and what you want next
  • Design previews for front-end work
  • Email support, one working day

Business

For agencies and multi-client work.

$119.99 per month, plus seats

50 GB · unlimited targets · billed annually, $360 a year less

Everything in Pro, plus:

  • 50 GB, and unlimited deployment targets
  • 25 concurrent runs
  • Per-client project isolation — separate teams, targets and boards
  • Audit log export
  • Named contact and onboarding

No monthly run allowance to use up, and nothing resets. Full pricing and comparison.

Objections

The questions you are actually asking

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 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 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.

Still circling something? Ask us directly — a person replies.

You do not need another coding tool. You need an engineering department.

Give Capy your idea — or the codebase you already have. Tell it what you want. It handles the engineering. Start in Manual mode: nothing runs until you say so.

No card required · Free plan forever · Export everything, any time