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.
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.
Before you ask
The three questions everybody has
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 sets out where your data sits.
Something else on your mind? Ask us — a person replies.
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