Ship software at scale

Most tools that promise to write software for your team ask you to trust the output. That is the wrong thing to ask an engineering manager. You already have a review process, branch protection, CI and people whose job is to say no to a risky change — and none of that should have to move for a new tool to be useful.

code-anything is built around that constraint. Work happens in an isolated sandbox, gets verified against your own typecheck, tests and build, and arrives as a pull request on its own branch. Your reviewers hold the merge button, exactly as they do for a human contributor. The worst case for a bad suggestion is a PR nobody merges, which is a failure mode your team already knows how to handle.

The second audience matters just as much. Operations, finance, support and marketing people describe the internal tool they need in plain language and get a working, hosted app on a real preview URL — with the Postgres data layer, sign-in, the sending code and Stripe checkout already written in. That work does not queue behind your roadmap, and it does not arrive as another spreadsheet nobody owns.

The rest of this page is the evaluation material: how collaboration and change control work, what the security and data posture honestly is today, how access, monitoring, support and billing are handled, and a plain matrix of what is available now, what is on request, and what simply does not exist yet. Where a certification or guarantee is not something we hold, this page says so. Read it alongside the security practices page, the platform overview and pricing.

It is worth being precise about the current state, because “shared workspace” means different things to different vendors. Today a project has a single owner account. Shared workspaces with named roles are listed on the Team plan and sit on the near-term roadmap; they are not something you can switch on this afternoon.

What that means practically is that the multi-person part of the workflow lives where multi-person software work already lives. The agent proposes; your repository disposes. Reviewers, required checks, CODEOWNERS and merge rules on your GitHub repo apply to an agent-authored pull request exactly as they apply to a human one, because it is an ordinary pull request. And when a project needs to change hands, you can generate a handover document — a machine-readable manifest of the repository, the database, the hosting project and every provider connection, marked by whether it transfers or has to be reissued. The handover request is recorded; moving the account itself is still a conversation with us rather than a one-click action.

The agent never operates on your working tree. It clones the repository into a sandbox, indexes it so it understands structure rather than matching text, edits there, and pushes to a branch of its own, against your repository’s default branch as the base. The token that opens the pull request is a short-lived GitHub App installation token needing only contents and pull-request write, and it is written into the sandbox filesystem with restrictive permissions and scrubbed on exit rather than passed on a command line — so it never lands in exec logs or shell history.

Before anything reaches you, the change has to survive your own checks inside the sandbox: typecheck, tests, build, and a runtime check on the resulting preview. Work that fails is repaired or reported rather than handed over for you to discover in review. Separately, a permission engine classifies each action the agent wants to take; anything it escalates stops the run and waits for an explicit approve or deny from a person. More detail lives on the GitHub PR agent and sandbox verification pages, and the end-to-end sequence is drawn out on the platform page.

Here is what is true. Builds and edits run in isolated, ephemeral sandbox clones, one per workspace, torn down when the work completes — so one project’s execution cannot reach another’s data. Changes to your repositories are made only through reviewed pull requests. Application data and authentication run on managed Postgres with row-level security. Data is encrypted in transit with TLS. Credentials are encrypted with AES-256-GCM before storage, with the master key held only in the control plane. We monitor the service continuously for availability, errors and suspicious activity, and we follow least privilege for access to systems holding customer data.

Here is what is not true, stated as plainly as we can. We hold no formal security certifications — not SOC 2, not ISO 27001, not a HIPAA attestation — and we do not claim any. We have not published a third-party penetration test. We do not offer a contractual uptime SLA; our terms provide the service “as is” and “as available”. There is no self-hosted or in-your-own-cloud deployment. If any of those is a hard gate in your procurement process, the honest answer today is that we do not clear it, and we would rather you know that in the first conversation.

We take responsible disclosure seriously: if you believe you have found a vulnerability, email security@code-anything.com before disclosing publicly, and we will work with you to resolve it. The full, current posture is written up on the security practices page, and it is deliberately written not to promise more than the product does. As we earn certifications or complete independent audits, they will be listed there first.

Ownership is settled in the terms rather than in marketing copy: you own the code and content you create with the service, and we claim no ownership of your projects. We take only the limited licence needed to host and process that content in order to run the service for you. The output is ordinary source code in a repository you control, so leaving is a matter of keeping your repo, not extracting yourself from a proprietary format.

Retention follows the same principle: information is kept while your account is active or as needed to operate the service, meet legal obligations and resolve disputes, and is deleted or anonymised when it is no longer required. Depending on where you are, you may have rights to access, correct, export or delete personal information, and you can exercise them by writing to us. The subprocessor list, the retention language and the contact route are all on the Privacy Policy; commercial terms are on the Terms of Service. A signed data processing agreement or custom contract terms are an on-request conversation — ask, and we will tell you what we can sign today rather than implying more.

To be clear about the limits: continuous monitoring and alerting is a real operational practice, not a contractual availability commitment. We do not publish an uptime SLA, and our terms provide the service without a guarantee that it will be uninterrupted or error-free. What we do commit to in the product is visibility — health checks on builds, deploys and previews, alerts that carry context, versioned rollback, and a correlation id that ties a request to the run and sandbox that served it. The agents page covers how the always-on checks work, and workspace monitoring covers what is watched.

Billing is monthly, in advance, through Stripe, and each paid plan carries an allotment of build credits that resets every billing period — unused credits do not roll over. Usage beyond the allotment is handled by buying additional credit packs rather than by a surprise invoice, so a busy month has a ceiling you chose rather than one you discover. You can cancel at any time and the plan stays active until the end of the period; fees are non-refundable except where the law requires otherwise. Pricing and inclusions are set out on the pricing page.

The parts that are not self-serve, said plainly: annual terms, invoicing, purchase orders and bespoke contract paperwork are not something you can configure in the product today. Neither is a signed DPA or a negotiated security addendum. All of them are conversations we are happy to have — email us with what your procurement process requires and we will tell you what we can do now and what we cannot, rather than letting it stall three weeks into a review.