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.
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.
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.
Built it with an AI yourself and daren't touch it now? That is a different problem with a different answer — start here.
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.
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.
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.
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
Connect GitHub, GitLab or any git remote. 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.
You attach the repository
Connect the git remote 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.
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.
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.
No rewrite, no migration, no discovery phase you pay for before anything moves.
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.
Before
It thinks before it changes
During
Every task gets its own branch
T-02 task/t-02-auth-migration → .worktrees/t-02
T-04 task/t-04-sca-challenge → .worktrees/t-04
T-05 task/t-05-challenge-modal → .worktrees/t-05
When it is unsure
It knows when to ask you
Opened by the failed deployment of REQ-142
Read journalctl -u your-api on prod-web-1
Cause found — SCA_PROVIDER_KEY is not set on the production host
Opened REQ-143 to add the variable to the deploy configuration
The whole model, including what an investigation may and may not touch: read the security and governance page.
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
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 when you want the detail.
Still circling something? Ask us directly — a person replies.
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.