Bring in an expert to build with you

A partner on code-anything is an independent builder — a studio, an agency, a consultancy or a capable freelancer — who takes on client work and uses this platform to deliver it. They are not our employees, not a support tier you can escalate into, and not a reseller of a licence. They are the people you hire when you want experienced hands on the work, and the platform is simply the tooling they build with.

That distinction matters because of what the product already does on its own. You can describe an application in plain language and get a working, hosted version running on a preview URL, with the Postgres data layer, sign-in and the sending code already written in from vetted bricks. Changes to a connected repository arrive as reviewed pull requests rather than mystery commits. The mechanical labour of software — scaffolding, wiring, the fourteenth CRUD screen — is not the thing you are short of any more. The platform overview walks the whole sequence, and the capability pages go feature by feature.

What has not changed is judgement. Somebody still has to decide what the software should do, which trade-offs are acceptable, what the data model should have been in the first place, and whether a build that passes every check is actually correct for the business it serves. That is what you are buying from a partner: not typing speed, which is no longer scarce, but the accumulated experience of having got this wrong before and knowing where it goes wrong next.

The rest of this page is written to be useful whichever side of the table you are on. If you are considering hiring someone, there is a section on when that is the right call and when it is an expensive way to avoid writing a brief, what kinds of engagement partners actually take, how to brief one properly, what to expect commercially, and where our responsibility ends and theirs begins. If you build software for clients and want to work with us, the programme section says plainly what exists today and what does not.

There is a pattern worth naming: the strongest engagements start after the client has already built something. A rough prototype does more to align expectations than any specification document, because it converts a conversation about adjectives into a conversation about a screen. It also means you are paying a partner for the difficult 20% instead of paying them to discover what you wanted. If you are hesitating, spend a day with the templates, a use case for your industry or role, or one of the reference patterns, then decide.

The opposite pattern is worth naming too. If the reason you want a partner is that you cannot get a clear answer internally about what the software should do, an external firm will not supply that answer — it will bill you while you find it. Settle the internal disagreement first; it is much cheaper on your own time than on someone else’s day rate.

Two of these deserve more attention than they usually get. The first is data modelling. Every project that stores data gets its schema, migrations and access layer written for it, so nobody hand-rolls that — but the shape of the tables is a decision with a decade-long half-life, and it is almost impossible to change cheaply once real records are in them. If you hire a partner for exactly one thing, hire them for that.

The second is ownership after launch. Shipping is the start of an obligation rather than the end of one: dependencies age, integrations change their APIs, the business asks for something new every fortnight, and health checks are only useful if a person reads them. Workspace monitoring runs the checks and raises the alert, but it does not decide what the alert means. Agree who does before you need to know.

Before you scope any of these with a partner, be clear about what the platform already does unaided, so you are not paying twice for it. The capability pages cover each piece — prompt to app, live preview, Go Live, the managed backend, the GitHub PR agent, code intelligence and sandbox verification — the integrations page lists what connects natively, and the documentation is the honest reference for the workspace itself. The enterprise page carries the change-control and security posture a partner will be asked about in your procurement review.

One structural advantage worth using: on code-anything, scoping happens in a chat conversation before anything is built. The agent asks questions, and the answers become a blueprint you review and confirm before the first build starts — and the whole conversation is stored with the project. That makes the brief a shared artefact rather than a meeting someone half-remembers, so whoever picks the work up in six months reads the same brief the build was made from. The quickstart in the docs shows what a good opening description looks like, and the concepts section covers the vocabulary a partner will use with you.

Review the same way. Stakeholders judging a running preview give better feedback than stakeholders reading a status report, because the thing they are reacting to is real. Ask your partner for a preview link at the end of every meaningful slice, not a demo at the end of the month — and when something is wrong, describe the change rather than filing a ticket that describes a description of the change.

Partners set their own rates, and we neither publish nor standardise them. That is not evasion — it genuinely varies with the market a partner works in, the domain, and how much of the outcome they are taking responsibility for. What we would advise on any engagement is to buy a small, fixed, well-defined slice first. A paid discovery week or a single shipped feature tells you more about whether the working relationship fits than any pitch deck, and it is a cheap way to be wrong.

Keep the two costs mentally separate. Your code-anything subscription is billed to your own account through Stripe, monthly and in advance, with an allotment of build credits that resets each period; a partner’s fee is a separate commercial relationship on their terms. Decide upfront whose account the project lives on during the build and who is paying for the plan. The free tier covers the prompt-to-preview loop on a single project; going live on a custom domain starts at Starter; and connecting a GitHub repository, Stripe payments and continuous workspace monitoring are listed on Pro and above. The pricing page sets out exactly which tier carries which of those, including how build and runtime credits are metered.

Put ownership in writing on both sides. You own the code and content created with the service — we claim no ownership of your projects — but that is our position, not automatically your partner’s. Agree that the repository belongs to you, that it lives under your organisation from the first commit rather than being migrated at the end, and that credentials are issued to you rather than held personally by a contractor. The output is ordinary source code, which is the best insurance a services engagement can have: if the relationship ends, you are left with a normal codebase, not a proprietary artefact only one person can open.

One consequence is that partner engagements here tend to be shorter and more senior than traditional agency work. The hours that used to go into implementation go into deciding, reviewing and hardening instead. If a proposal you receive is priced as though every screen has to be hand-built, ask what the platform is doing in their plan — a partner who works this way should be able to answer immediately, including which parts they intend to hand to the standing agents rather than staff with people.

The security and change-control detail a partner will be asked about during a procurement review — sandbox isolation, the credential vault, what we deliberately do not claim, and the certifications we do not hold — is set out in full on the enterprise page. Point your reviewers there rather than having a partner paraphrase it.

There is no partner directory. There are no listing pages, no profiles, no search, no matching engine and no application form in the product. There is no certification, no accreditation, no badge, no tier structure and no exam. There is no referral scheme, no commission and no revenue share, because there is no mechanism for money to pass between a partner engagement and us. If you have read a partner page before, you will recognise how much of the usual furniture is missing here; that is deliberate, and we would rather say so than describe a programme that does not exist yet.

What does exist is an email address and a genuine interest. If you build software for clients and you want to work with us, tell us about your practice and we will get back to you. If we can usefully introduce you to someone who has asked for help, we will. As this becomes something more structured, it will be built in the open like everything else, and what is planned will appear on the roadmap and ship notes in the changelog before it appears as marketing copy on this page.

In the meantime, the most productive thing a prospective partner can do is build with the thing. Read the docs, connect a real repository and take an agent-authored pull request through your own review process, publish something to the showcase, and tell us where it broke. It also helps to know where we sit against the tools your clients already ask about — the comparison pages are written for exactly that conversation, and the blog is where the longer arguments go. Our community channels are still being set up, so for now the fastest route to us is simply an email.