The fastest way to understand Kaer is to see what people actually ship with it. The operator plans the work, runs code in a per-session VM, and delivers a result you can review — which means the useful question is not "what can it do" but "what is the next concrete thing you would hand it." The examples below are grouped by who tends to reach for them first.
For engineering
Engineering teams use Kaer to ship features in their own repository. Connect a GitHub repository and the operator reads the codebase, makes the change, and opens a pull request that runs your existing CI. It does not replace your test suite; it works to keep it green.
Because the operator branches, several tracks can move at once — a refactor, a bug fix, and a new endpoint in parallel, each landing as its own reviewable pull request. Every file it touches is plain text in your repo, so you can open it in your editor and take over at any point.
For operations
Operations teams use Kaer to build internal tools without waiting on a backlog. Describe a back-office process that hurts — a dispatcher view, a refund-approval queue, a cohort survey with a follow-up drip — and the operator builds the tool itself: the data model, the screens, and the logic between them.
These tools can ship with guardrails in place, including role-based access per surface and an audit trail of what was done. Routing the results outward is its own step: connect Slack for notifications or Mail AI when output needs to leave the dashboard.
For founders
Founders use Kaer to move from idea toward revenue without hiring first. The operator handles the parts you would otherwise bring someone on for early — backend, payments, authentication, an admin dashboard — so a very small team can ship like a larger one.
A realistic first week is a sequence of turns rather than one giant leap: a landing page and waitlist, then auth and Stripe, then the core app, then onboarding emails. Each one is reviewable before it goes live, so you stay in control of what actually ships.
How to start
Pick the use case closest to yours and give the operator the first concrete step — not the whole vision. "Add a billing tab to the admin dashboard" beats "build my startup," because a clear finish line is far easier for the operator to steer toward.
If you are new, read Getting Started first and run a single turn end to end. When you want the operator to reach your existing tools, set those up in Connectors. When the work needs to run on its own, Automations and Workflows are the next places to look.