For owners without a developer on staff
You know what needs to change.
You just can't change it yourself.
A customer can't check out in Germany. You want to add a monthly plan. Onboarding needs one more step. You know exactly what the product should do — you just don't have a developer to make it happen. Not because yours left. Because there was never one on staff, and there is no good reason to hire an agency for a half-day change. Capybari takes the request in your own words, plans it, builds it, and ships it only after you approve.
Capybari keeps a product you already have moving. It is not a from-scratch app builder — it needs a repository to work in.
The short version
You are not technical. You don't need to be.
You don't need to read code. You don't need to write a specification. You don't need to know what a branch is.
You describe the outcome in your own words — "add a monthly plan", "customers in Germany can't check out" — and Capy works out the rest. Your job is to read the plan and say yes.
Who this is for
You own it. Somebody else built it.
The agency-built store
It works and it sells. Every change is a quote, a queue and a fortnight.
The indie SaaS owner
Paying customers, a roadmap in your head, and no engineering hire on the horizon.
The ops lead with a backlog
You know the five things that would help. They have been "next sprint" since spring.
If somebody did build it for you and has since disappeared — and now nobody can read the code — that is a different problem: start here.
Ship product changes without a developer
The three things you actually do
Everything else is Capy's job. These three are yours, and none of them requires you to know how the software is built.
Say what you need
In your own words. A sentence is enough. You never have to describe how to do it.
Read the plan
Capy writes it in plain English, so you can tell whether it understood you. If it didn't, say what it missed and it plans again.
Say yes
Nothing is built from a plan you haven't read. Nothing ships that you didn't agree to. That is the whole job.
What you can ask for
Complete requests, exactly as people say them
Not one of these says how to do it. That is deliberate — working out the how is the part you are handing over.
- “Customers in Germany can’t check out.”
- “Add a monthly plan alongside the annual one.”
- “Change the pricing page to show the new tier.”
- “Fix the bug where the confirmation email doesn’t send.”
- “Add a step to onboarding that asks for company size.”
- “The dashboard takes more than five seconds to open on mobile.”
- “The export button doesn’t work on mobile.”
- “Add a free trial instead of a demo call.”
Start with one stuck change
Read the plan it writes back. Nothing runs until you say so.
You need a git repository and one thing you want changed. Nothing else to prepare.
After you say yes
What happens while you get on with your day
You do not have to follow any of this to use Capybari. It is here because people reasonably want to know what "it builds it" actually means.
It is checked before it reaches you
Other specialists review the work
Then it goes live
And Capy watches to see it worked
Merged 4 branches, no conflicts
Deployed to prod-web-1 over SSH
Health check failed — /healthz returned 503 twice
Rolled back to a3f91c2 — the last commit known healthy
Investigation INV-11 opened automatically
None of that needs watching. What you get instead is the brief, below.
The daily brief
How you stay in control without living in the tools
You are not meant to sit in a dashboard watching work happen. Capy carries on while you are doing your actual job, and when you come back it walks you through each project in turn. Fifteen minutes a day and you are current.
What moved
What was finished since you last looked, and what went live. In sentences, not commit messages.
What needs you
The one or two decisions only you can make, each with what Capy recommends and why — so you are agreeing or disagreeing, not researching.
What you mentioned
Anything you said in passing that ought to become work. Say yes and it becomes a request; say no and it goes away.
A project counts as briefed when you say you are done with it — not when the page loaded — so a brief you abandon halfway does not silence tomorrow's.
What the first week looks like
From "I can't change it" to a change shipped
There is no onboarding project and no discovery phase. The point of the first week is one real change, so you find out what this is like before you commit anything to it.
You connect the repository
Wherever your code lives. If you are not sure, whoever built it can tell you in one message. Nothing is changed and nothing is deployed.
You get the first brief
A description of your own product in plain English. For a lot of owners this is the first time anyone has written that down.
You name one thing
The fix you have been putting off, or the change a customer keeps asking for. One sentence.
You approve the plan
Read it. If it understood you, say yes. If it did not, say what it missed. Nothing runs before that.
The change is live
Built, tested, reviewed and deployed — and you approved it before it went. The thing you could not change is changed.
How hands-off you are is a separate dial, and it starts at the cautious end. Every project begins on Manual, where nothing runs until you press the button. Move to Supervised when the plans stop surprising you — or never. It is not a setting you are expected to grow out of.
You approve. You don't supervise.
Nothing ships that you did not agree to
Three things stand between "customers in Germany can't check out" and anything reaching the product you are selling. None of them is a setting you have to remember to switch on.
First
You read the plan, in English, before anything is built
Then
The work happens on a copy, never on your live product
And after it goes live
If it goes wrong, it is put back without you noticing
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
Technical decisions Capy makes. Business decisions — anything your customers will feel — it stops and asks you about, with a recommendation and the reason for it. The whole model is on the security and governance page.
Versus a coding assistant
If you have already tried an AI coding tool, this is the difference
You could try to do this with one. Describe what you want, watch it write code, test it, find it half right, explain again, watch it try again — and get there eventually, if you have three days and the patience to hold its hand through every decision. Capybari is for when you would rather hand the whole thing over.
| A coding assistant | Capybari |
|---|---|
| Needs you at every step | Asks only when it genuinely needs a decision |
| Makes you break down the work | Plans the work itself |
| Stops when you stop typing | Keeps going while you do something else |
| You check whether it worked | Tests, reviews and a security pass before it ships |
| You deploy it | Deploys it, watches it, and undoes it if it went wrong |
Both are useful. They are not the same kind of thing, and the difference is who is holding the work.
The questions people actually ask
Using Capybari without a developer
I don't understand code. Can I really use this?
Yes. You describe the outcome in plain English and read the plan in plain English. If you can explain what you want to a freelancer, you can use Capybari. The plan is the translation layer, and it exists precisely so that reading code is not part of your job.
What if the plan it writes is wrong?
Reject it, or say what it missed and have it planned again. Nothing is dispatched from a plan you have not approved. If it misunderstood you, that is obvious when you read it — which is the reason it is written in plain English rather than as a technical document.
Do I have to give it access to my servers?
Only if you want it to deploy. Plenty of people use Capybari for planning and building alone and deploy themselves, or never connect a server at all. Write access to a live server 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 writes up the cause, then opens a follow-up request with the fix. Nothing on the host is changed.
What does it cost to find out?
Nothing. The free plan carries one project and your own code, with no card required — enough to describe one change and read the plan that comes back. The plans are here when you want the detail.
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 a customer keeps asking for. Point Capy at the code, describe the outcome, and read the plan it writes back. Nothing runs until you say so.