If you build client apps for a living with AI tools, the building part is solved. The hand-over is not.
Org invites. Billing migrations. Credential ceremonies. Every single client.
Client work deserves a platform shaped like the job: your agent provisions a full stack
per client, the client tests the live app from day one, ownership transfers cleanly,
and you keep maintain access for the retainer.
Paste this into your coding agent and watch the whole loop run:
Please build me a demo with the Run402 CLI using the complete files at run402.com/llms.txt
Free prototype tier·AWS Aurora in production·No signup for you or your client
Everyone building for clients hits the same wall. The building part works. The hand-over doesn’t.
You build under your own accounts because asking a non-technical client to sign up for a cloud platform before work begins kills deals. Now you have 5 client projects under your name, each with separate billing, separate credentials, and a growing list of things you need to remember to transfer when the project ships.
Project transfers on the usual platforms require both parties to hold accounts. The client joins your org. Billing migrates separately. The frontend lives on one platform and the data on another, so the hand-over happens twice. One step breaks and you’re untangling it on a weekend.
10 clients = 10 dashboards, 10 organizations, 10 sets of credentials to manage. No fleet view. No way to delegate infrastructure provisioning to the AI agent doing the actual build. You’re the bottleneck in your own workflow.
Designed for client work end to end: agent-provisioned full stacks, no client signups, a clean transfer, and maintain access that outlives the transfer.
Your AI agent reads the CLI-first guide and runs the shared deployment workflow. It plans the release, stages files, applies migrations and activates the app. Your client can test the returned live URL while you build; deployment and verification results remain separate.
# Create run402.json and all files from the first-deploy guide. npm install -g run402@latest run402 up --check run402 up --name acme-portal -y run402 up verify # Inspect the actual site/console URLs and verification report.
When the project ships, offer it to your client by email. They accept it from the link and the project is theirs: their billing, their credentials. The recipient reviews the ownership and billing changes before accepting. Existing secrets and CI bindings need the rotation/rebinding steps named in the preview.
# Offer to an intended recipient; retained access is an explicit offer. run402 transfers create --to client@acme.example --project prj_example --retain-member developer run402 transfers preview trf_example # The recipient reviews the preview, then accepts from their own principal. run402 transfers accept trf_example --accept-retained-member # Use returned IDs. Review billing, revoked CI bindings and secret rotation.
The client owns the project and pays for it. With the recipient’s explicit acceptance, you keep developer access, so “can you fix the header” is a message to your agent, not a re-onboarding project. Retainer revenue without holding the client’s app hostage. The client can revoke your access whenever they choose; you were never in the way.
# After the transfer: 1. Client owns the project and its billing 2. Retained developer access requires the recipient’s acceptance 3. "Fix the header" arrives → your agent redeploys 4. Client can revoke your access at any time Same agent. Same project. Ongoing revenue.
Everything your agent needs to build and ship a real client app. Not a toy. AWS infrastructure behind it.
/rest/v1 patterns your agent already knows*.run402.com subdomainsSpin up a project for each client. Each is its own isolated lease. Free prototype for testing the workflow, then $5 to $20 per month per production project.
Pay from an allowance funded by card your agents spend as an allowance, or let the agent pay per call over machine rails (x402, or MPP on Tempo or Bitcoin Lightning). Two equal paths, your choice. Each client project can be its own tier. Optional: KMS signers for on-chain signing, $0.04/day per wallet plus $0.000005 per call. Non-custodial. See /billing/.
You’re putting your clients’ production apps on this. Here’s what’s under the hood so you can make that call with confidence.
Database AWS Aurora Serverless v2 (Postgres 16), multi-AZ Hosting CloudFront + S3 (wildcard *.run402.com) Encryption At rest (Aurora + S3) and in transit (TLS) Backups Automated, 7-day retention Isolation Each project gets its own Postgres schema Billing Hard-capped. No overages. No surprise invoices. Status status.run402.com
Each project is isolated. One client’s data is never accessible to another. Leases expire cleanly with a ~104-day soft-delete grace. The client’s live site keeps serving throughout; deploys and secret rotation lock after day 14; permanent deletion at day ~104. Renew anytime during grace to reactivate instantly.
Slots into the AI-assisted workflow freelancers and agencies are already running. No new platforms. No new tools.
Lovable Read /llms.txt → prepare complete files → run402 up Bolt.new Same: a shell-capable agent follows the CLI guide and verifies the result Cursor CLI in the agent shell; MCP adapter only for a tool-native host Replit Plain HTTP: agent speaks to api.run402.com directly Any agent Read https://run402.com/llms-cli.txt and build
Familiar REST patterns
(/rest/v1,
JWT auth, RLS policies) mean your agent doesn’t need to learn a new SDK.
Everything you need to know before putting a client project on run402.
A full stack operated through a CLI over the typed SDK and HTTP API: no dashboards, no signups, no human setup steps. The CLI deployment workflow gives your AI agent a Postgres database, a REST API, user auth, file storage, row-level security, and site hosting (static and Astro SSR). Everything lives on AWS (Aurora Serverless v2, CloudFront, S3).
It was built for the pattern freelancers and agencies live in: AI-assisted builds, multiple concurrent client projects, and the need to hand things over cleanly when the project ships. The core design decision is that no account creation is required, not for you and not for your client. Each person and agent uses its own identity; scoped grants and revocable credentials determine access.
The name comes from HTTP status code 402 Payment Required: reserved since 1997, finally useful now that AI agents can pay for what they use.
Use the CLI by default. Ask a shell-capable coding agent to follow the complete first-deploy tutorial, or run the visible commands yourself.
Use the typed, opinionated SDK for TypeScript/JavaScript programs and MCP for MCP-native hosts. The API remains available for deliberate lower-level integrations.
No crypto needed. Two payment paths, equal standing. You pick whichever fits your setup:
For most freelancers and agencies, an allowance funded by card is the simplest path: one allowance, N client projects, top up when needed.
This is the question the platform was built to answer. The short version: access and payment are separate concerns, and you control both independently.
Here’s the transfer flow, as a two-key system:
The payment side transfers independently of access. You can hand over billing while keeping maintain access (the retainer arrangement), or step away entirely and let the client revoke you. The project doesn’t care which wallet is funding it; it just needs an active lease.
The same access-grant / access-revoke mechanism covers every multi-party scenario: a freelancer plus the client’s in-house developer, an agency team sharing a project, a subcontractor with temporary access.
After the transfer, the client owns the project and pays for it. You stay a member with deploy access until they decide otherwise.
In practice: the maintenance request arrives, your agent (which already knows the project) makes the change and redeploys, and the client’s live site updates. No re-onboarding, no credential archaeology, no “can you add me back to the org” thread.
The client’s side of the bargain: revocation is one action, theirs alone, any time. Maintain access is a working relationship, not a hostage situation. That is what makes it easy for clients to say yes to.
No. That’s the whole point.
Account creation isn’t required at any stage: not for provisioning, not for access, not for the client. Access follows each principal’s membership or scoped grant. Invite collaborators or issue narrowly scoped, revocable credentials; do not share an owner’s private keys.
This is what makes client transfers fast. Your client doesn’t sign up for anything, doesn’t join an org, doesn’t set up billing before they even own the thing. They claim the project and it works.
Yes. The infrastructure is AWS-grade: Aurora Serverless v2 (Postgres 16, multi-AZ), CloudFront + S3 for hosting, TLS everywhere, automated backups with 7-day retention. Each client project lives in its own isolated Postgres schema; one client’s data is never accessible to another.
The prototype tier (free) never expires — one testnet payment, once — so a client project can start there and move to a paid tier when it needs the capacity. The $5/month Hobby tier and $20/month Team tier are production leases with real billing and real durability guarantees.
Hard caps, no overages. Every lease has a hard ceiling on storage and API calls. You will never receive a surprise invoice for a client project that got unexpectedly popular.
Run the whole loop free: your agent builds a real project, your client sees it live, and you feel what the transfer is like when it actually works.
Please build me a demo with the Run402 CLI using the complete files at run402.com/llms.txt
Free prototype · No credit card to start · No account for your client